---

What this org is about

Custody is a Hugging Face organization for exploring a simple but increasingly important engineering question:

Who has control of an asset, capability, secret, instruction, or decision at any given moment?

In software, custody is usually associated with things like:

• keys,
• credentials,
• funds,
• files,
• models,
• data,
• permissions.

In agentic systems, the same idea becomes much broader.

An AI system may temporarily hold:

• access to a tool,
• permission to modify a file,
• authority to send a message,
• a payment capability,
• a user instruction,
• a sensitive document,
• a workflow state,
• a delegation from another agent.

That creates a real custody problem.

Not everything an agent can access should automatically become something it can freely use.

---

The basic model

A custody system usually has four questions:

what is being controlled?
who currently controls it?
what are they allowed to do?
how does control move to someone else?

That sounds obvious.

In practice, many systems blur these questions together.

For example:

can read
≠
can modify

can modify
≠
can publish

can publish
≠
can transfer ownership

has access now
≠
should keep access forever

A useful custody layer keeps those distinctions explicit.

---

Why this matters for AI systems

Agents are increasingly able to act across external systems.

They may:

• call APIs,
• write files,
• access repositories,
• use credentials,
• move data,
• trigger transactions,
• create other agents,
• change configuration,
• communicate on behalf of a user.

At that point, "does the model know what to do?" is only half the problem.

The other half is:

Does the system still know who is responsible for the thing being acted on?

Custody gives us a way to model that.

---

What I want to explore here

This org is for practical experiments around:

• delegated authority
• temporary permissions
• asset ownership
• handoff protocols
• credential scope
• chain of custody
• multi-agent responsibility
• approval boundaries
• revocation
• escrow-like control
• human / agent co-control
• auditability
• capability transfer
• safe release conditions

---

A software view of custody

A minimal custody record might look like this:

{
  "asset": "customer-export.csv",
  "custodian": "analysis-agent",
  "permissions": [
    "read",
    "summarize"
  ],
  "forbidden": [
    "publish",
    "external-transfer"
  ],
  "delegated_by": "user",
  "expires_at": "2026-09-18T12:00:00Z",
  "handoff_requires": "explicit-approval"
}

The point is not the JSON format.

The point is that control becomes inspectable.

You can answer:

• who has custody,
• what that custody permits,
• who granted it,
• when it expires,
• what happens next.

---

Custody is not the same as access

This distinction matters.

A system may technically be able to access something while not being the legitimate custodian of it.

For example:

credential exists in environment
→ agent can technically use it

but

credential was not delegated for this task
→ agent should not use it

That gap between technical capability and authorized custody is exactly where a lot of agent-control problems begin.

---

Things that can have custody

Custody does not need to mean money or cryptographic keys.

It can apply to almost any controlled resource:

Data

documents, personal data, datasets, memory, logs

Capabilities

tools, APIs, execution rights, browsing, payments

Identity

accounts, credentials, delegated user identity

Artifacts

code, drafts, reports, generated files

Decisions

approval rights, release authority, escalation authority

Workflow state

task ownership, handoff responsibility, checkpoints

Models

weights, adapters, private endpoints, deployment rights

---

Possible spaces

A few projects that fit this org naturally:

• Agent Custody Manager
• Delegation Boundary Lab
• Capability Escrow Simulator
• Chain of Custody Explorer
• Credential Scope Designer
• Agent Handoff Protocol Lab
• Custody Transfer Visualizer
• Permission Expiry Planner
• Human Approval Escrow
• Multi-Agent Responsibility Map
• Asset Release Gate
• Delegated Authority Inspector
• Temporary Access Simulator
• Custody Drift Detector
• Agent Ownership Ledger

---

A custody lifecycle

One useful way to think about custody is as a state machine.

UNASSIGNED
    ↓
GRANTED
    ↓
IN CUSTODY
    ↓
USED
    ↓
HANDOFF REQUESTED
    ↓
TRANSFERRED
    ↓
REVOKED / RELEASED

There should be a clear reason for every transition.

Especially:

grant
transfer
extend
revoke
release

Those should never be invisible side effects.

---

What makes a good custody system

A useful custody layer should make these things obvious:

1. Holder

Who currently has control?

2. Scope

What exactly may they do?

3. Origin

Who granted the authority?

4. Duration

How long does the custody last?

5. Transfer

Can custody be delegated further?

6. Revocation

Who can take it back?

7. Evidence

What record proves what happened?

If one of those is unclear, custody becomes ambiguous.

And ambiguous custody is where accidental authority expansion tends to happen.

---

Delegation should not silently widen authority

A common failure pattern looks like this:

user
↓
agent A
↓
agent B
↓
tool

The mistake is assuming that agent B automatically inherits everything agent A could do.

It should not.

A safer model is:

user grants:
read + summarize

agent A delegates:
read only

agent B receives:
read only

tool receives:
minimum capability required

Authority should usually become narrower as it moves deeper into a workflow.

Not broader.

---

Chain of custody

For important assets, it should be possible to reconstruct the full control history.

Something like:

09:14  user created asset
09:15  user delegated read access to agent-a
09:17  agent-a produced derived artifact
09:18  agent-a requested publish authority
09:19  user approved publication
09:20  publishing-agent received one-time capability
09:21  publication completed
09:21  capability revoked

That is much easier to reason about than:

the agent had access

---

Custody and multi-agent systems

Multi-agent workflows make custody especially interesting.

When several agents collaborate, responsibility can become blurry very quickly.

For example:

• one agent discovers information,
• another edits it,
• another validates it,
• another publishes it.

Who owns the final artifact?

Who may discard it?

Who may override validation?

Who is responsible if it is transferred outside the system?

Those are custody questions.

---

Temporary custody is often better than permanent permission

A lot of agent infrastructure still grants permissions like this:

allow forever

That is convenient.

It is also usually more authority than the task needs.

A more useful pattern is:

grant capability
↓
perform task
↓
verify completion
↓
revoke capability

This turns access into a bounded session of custody.

---

Escrow is an interesting model

Some actions should require more than one party before custody changes.

For example:

agent proposes transfer
        +
policy approves scope
        +
human approves release
        =
custody moves

That resembles escrow.

It is especially useful for:

• external publication,
• high-value transactions,
• destructive operations,
• sensitive data release,
• credential delegation,
• irreversible actions.

---

Custody failure modes

A few patterns worth testing:

stale permission

orphaned asset

unclear owner

delegation without consent

silent privilege expansion

custodian disappears

handoff not acknowledged

revocation fails

expired access remains usable

two agents believe they both own the task

asset transferred without a durable record

These are not only security failures.

They are coordination failures too.

---

What this org is not

This is not meant to be:

• a crypto custody brand,
• a wallet project,
• a generic cybersecurity collection,
• a permission dashboard with no real model behind it,
• an excuse to give agents more control.

The interesting part is not "how much can an agent control?"

The interesting part is:

How precisely can we define, transfer, limit, and revoke that control?

---

A simple architecture

┌──────────────────────────┐
│          ASSET           │
└────────────┬─────────────┘
             │
             ↓
┌──────────────────────────┐
│      CUSTODY RECORD      │
│ holder                   │
│ scope                    │
│ expiry                   │
│ delegation rights        │
└────────────┬─────────────┘
             │
     ┌───────┴────────┐
     ↓                ↓
┌──────────┐      ┌──────────┐
│  AGENT   │      │  HUMAN   │
└────┬─────┘      └────┬─────┘
     │                 │
     └──────┬──────────┘
            ↓
   APPROVE / TRANSFER
   REVOKE / RELEASE

The custody record is the part that keeps the workflow understandable.

---

Questions a good custody tool should answer

• Who currently holds the asset?
• Who gave them control?
• What can they do with it?
• What can they not do with it?
• Can they delegate it?
• For how long?
• What action ends custody?
• What happens if the custodian fails?
• Is the transfer reversible?
• Is there a complete audit trail?

If those questions have clear answers, the system is much easier to trust.

---

The direction

As agents become more capable, I expect custody to become a first-class concept in agent infrastructure.

Not only:

authentication
authorization

but also:

delegation
custody
handoff
revocation
release

That is the layer this org is meant to explore.

---

Short version

Custody is about explicit control.

This org explores how humans, agents, and tools can safely hold and transfer authority over data, capabilities, artifacts, credentials, and decisions.

The goal is not maximum autonomy.

The goal is making control bounded, visible, transferable, and revocable.

---