Applications / Agent Delegation

Who is acting, on whose behalf, and under what authority?

When an agent acts for someone, two questions can easily become one.

A person, who is responsible, passes bounded authority to an agent, which is the one acting.

Who is responsible for what the agent does? And what is the agent authorized to do? They are related, but they are not the same question.

A person can remain accountable for an agent while the authority available to that agent is separately bounded.

An agent does not need to become the person whose authority it acts under.

The agent can receive bounded authority.

Of the authority the person holds (read all repositories, write this repository, write other repositories, manage members), only write this repository is selected. Session issuance evaluates it against the requested scope, the person approving on their own device. The result is an agent session carrying write to this repository for 15 minutes at most, attributable to the person and held by the agent, which is not the person.

Suppose an agent needs to write to a specific repository on someone's behalf.

The person may already hold authority relevant to that action. The agent does not need everything associated with that person because it acts for them.

The immediate decision can be narrower:

The decision

May this agent receive a session carrying authority to perform this action on this repository?

In the tested implementation, the agent holds its own software key. The person approves each new session from their own device, presenting the requested grants and an accountable reference. Each session lasts no more than 15 minutes.

In that implementation, Krutho evaluates the authority the person already holds against the action and scope the agent has requested.

The resulting session remains attributable to the person while carrying only the selected authority requested for the agent.

The agent does not become the person, and it cannot create authority the person did not already hold.

Accountability can remain with the person while authority is bounded to the agent.

Being responsible does not make every action authorized.

Knowing who is responsible for an agent matters.

It does not tell us everything the agent should be allowed to do.

Krutho's implemented agent-session model selects explicit action and scope grants already established for the responsible person and signed into their credential.

If the requested authority was not presented, does not match or is no longer available, the session is refused.

Identity establishes accountability. Authority establishes a legitimate basis for action.

The person can remain the same while their authority changes.

The same person and agent relationship at two moments. The person, their device and their accountability for the agent stay the same. At the first moment their credential carries read and write authority, and new read and write sessions are issued. After the credential is updated, write is withdrawn: a new write session is refused while a new read session is still issued. The change affects later session issuance.
Implemented model, affecting later session issuance

Identity and authority do not necessarily share the same lifecycle.

In Krutho's implementation, withdrawing a grant does not require removing the person's identity, device or registered keys.

The person remains. Their authority changes.

A later request for a new session carrying the withdrawn grant is refused, while authority they still hold can remain available for a new session.

Changing what someone is authorized to do does not require changing who they are.

Different decisions can need different things.

One person across three related decisions. Creating a root credential requires identity proofing, labeled implemented. Using established authority requires possession, trust and relevant state, labeled implemented. Recovering after device loss, shown dashed and labeled architectural, not demonstrated, is where identity proofing can become relevant again.
Not one demonstrated agent lifecycle

Separating identity and authority does not mean identity becomes unnecessary.

A separate Krutho credential-authority implementation covers the first two decisions below. Recovery after device loss is architectural and not demonstrated.

Creating a root credential requires identity proofing.

Once authority has been established, using derived credentials can rely on possession, trust and relevant lifecycle state without repeating the original identity-proofing decision every time.

If authority needs to be recovered after device loss, identity proofing can become relevant again.

The person has not become less important between those moments.

The decisions require different things.

What a system needs to know should follow the decision being made.

Issuing the session is not the final decision.

Two stages with different responsibility. Issuance, implemented: the agent requests selected grants, issuance is evaluated against authority the person already holds, the person approves on their own device, and a short-lived, human-approved agent session is issued or refused. Receiving domain, shown dashed as architectural: the agent presents the session with a write request, and the receiving domain decides under its own requirements whether the authority is sufficient there, permitting or refusing the write.
Responsibility differs by stage

There are still two distinct decisions.

First:

Decision

May this agent receive a session carrying authority to write to this repository?

Then:

Decision

Is that authority sufficient to permit this write here?

Krutho has implemented the first decision.

The second belongs to the receiving domain.

That domain determines what it trusts, what authority it requires, what state must be available and what conditions apply to the requested action.

A session carrying valid authority does not create automatic permission.

The person remains accountable. The agent receives bounded authority. The receiving domain still decides.

Krutho can allow an agent to act through bounded delegated authority without requiring the agent to inherit the person's identity or everything the person is authorized to do.

The authority can remain specific to an action and scope.

Its validity can remain subject to lifecycle state and time.

And carrying that authority does not remove the receiving domain's responsibility for its own decision.

Evidence

What we have shown.

Krutho has implemented human-approved, short-lived agent-session issuance in which requested grants are limited to authority already signed into the responsible person's credential. The tested issuance path uses software keys. Each implemented session lasts no more than 15 minutes.

The implementation also shows that withdrawing a grant changes the authority available for a later session while the person's identity, device and key registrations remain.

The receiving-domain action evaluation described here remains an architectural consequence of that bounded delegation model rather than part of the exercised agent-session path.

Who is responsible and what is authorized are different questions.

How Krutho Works → Examine Partner Access →