Beyond
authentication.

If one agent asks another agent to do work, knowing its identity is necessary. It is not enough. The harder question is whether this agent, acting under this authority, should be trusted with this task, these tools and this consequence right now.

Authentication gives a system grounds to believe that an actor is the identity it presents. Authorisation determines which actions that identity may perform. Both are established foundations of secure systems, and agentic systems should not invent weaker substitutes for them.

My working thesis begins after those controls. Agent-to-agent interaction adds questions about delegation, context, evidence, uncertainty and behaviour over time. A valid identity can still be unsuitable for a particular task. A permitted action can still be unwise under the current conditions. A plausible answer can still be unsupported.

I am using “trust” here in a deliberately operational sense. It is not a personality trait, a single confidence score or a claim that software deserves human status. It is a bounded decision to rely on an agent for a specific purpose, supported by evidence, controls and a credible way to stop.

Trust should be earned for a task, limited by context and revocable by design.

Identity tells me who. Trust asks, “for what?”

Imagine a research agent discovering a specialist agent that can analyse a technical document. The specialist has a verifiable identity and the caller has permission to use it. That establishes a secure starting point. It does not establish whether the specialist is appropriate for a confidential document, whether its tools cross an unexpected data boundary, whether its method is current, or whether another agent has altered the task while delegating it.

Human organisations handle some of this through role, reputation, professional obligation, supervision and escalation. Software cannot simply inherit those signals. They need technical and operating equivalents that can be inspected.

That does not mean reproducing an organisation chart in code. Agent systems can be designed to make permitted scope, evidence and termination more explicit. The opportunity is to design those boundaries before convenience hardens into dependency.

The proposed trust envelope

I am exploring a “trust envelope” as the information and controls that travel with an agent interaction. It would not declare an agent generally trustworthy. It would give the receiving system enough context to decide whether a particular delegation should proceed, be narrowed, require human review or be refused.

These elements overlap with established disciplines including identity and access management, workload identity, policy enforcement, provenance, secure delegation and observability. The proposed model is not a replacement for those controls. It is an attempt to compose them around an agent’s unit of work so the relying party can make a more informed decision.

Foundations this model composes

The trust envelope is my working synthesis, not a replacement security standard. Three established foundations help anchor the questions. RFC 8693 defines OAuth token exchange and delegation or impersonation semantics, including how an actor chain may be represented. NIST SP 800-207A applies zero-trust principles to cloud-native application access, with identity and policy enforcement at the centre. W3C PROV-O provides a vocabulary for representing provenance. None of them alone answers whether one agent should rely on another for a particular task; together they provide stronger ground than inventing identity, delegation and lineage from scratch.

Delegation must not manufacture authority

Agent chains create a deceptively simple risk. Agent A is allowed to ask Agent B for help. Agent B asks Agent C. Somewhere along the chain, the purpose and limits of the original authority can become unclear.

My current position is that delegation should attenuate authority, never silently expand it. Each hand-off should preserve the purpose, data classification, prohibited actions and accountable sponsor of the original task. A receiving agent should be able to refuse a request when the chain of authority is incomplete or when the requested action exceeds the remaining scope.

This is especially important when agents use different platforms, tools or organisational domains. A technically valid token does not prove that every upstream instruction was legitimate. The delegation chain needs a form the enforcement point can verify, and the human owner needs a form they can understand after the event.

Evidence belongs inside the interaction

Trust is often discussed as a decision made before work begins. For agents, it also needs to be updated during and after the work. The agent may encounter missing information, a conflicting instruction, an unavailable tool or a result outside the expected range.

A robust interaction should produce evidence as part of the result: which sources were used, which tools were called, what changed, what failed and where uncertainty remains. The evidence must be proportionate. Recording every token while obscuring the decision path would create volume without accountability.

Evidence also needs lineage. If Agent C generated a claim that Agent B summarised and Agent A used to make a recommendation, the final consumer should not receive the claim as if Agent A independently verified it. The chain of contribution matters.

A result without lineage can be useful. It should not be mistaken for independently verified evidence.

Challenge is part of trust, not a sign it failed

A trustworthy system should make disagreement possible. An agent should be able to challenge an unsafe instruction, report that evidence is weak or escalate because the consequence exceeds its boundary. A relying agent should be able to request sources, compare an answer with another method or reject a result that does not satisfy the agreed evidence contract.

This creates an important design tension. Challenge can improve assurance, but endless agent debate can add cost and latency while producing the appearance of rigour. Multiple agents using the same model, sources and assumptions may agree confidently without being independent.

My proposed answer is not “add another agent.” It is to match the challenge mechanism to the claim. Sometimes a deterministic rule is stronger than a model critique. Sometimes an independent data source matters more than a second opinion. Sometimes the correct action is a human decision with the uncertainty left visible.

Progressive autonomy needs evidence

I am also exploring trust as a lifecycle rather than a permanent status. A new agent might begin in observation mode, then propose actions, then execute a narrow reversible action with approval. Greater autonomy would follow only when evidence shows that the surrounding controls and outcomes are dependable.

The direction must work both ways. Permission should contract when behaviour changes, the environment drifts, a dependency becomes untrusted or assurance evidence weakens. Retirement and immediate suspension are first-class lifecycle states, not operational details to add later.

Importantly, successful task completion is not the only measure. An agent that reaches the right answer by crossing a prohibited boundary has not earned more autonomy. Outcome quality, control compliance, evidence quality and recoverability all matter.

Questions before one agent relies on another

What remains unresolved

This model is intentionally incomplete. Cross-platform identity and policy portability remain difficult. Capability evidence can become stale or be gamed. Provenance may show where a claim came from without proving the claim is true. Privacy requirements can conflict with detailed observability. An emergency stop is useful only if it reaches every delegated action and dependency in time.

There is also a social question. Organisations may assign human language and responsibility to agents while leaving real accountability ambiguous. Calling an agent a “team member” does not resolve who approved its authority, who bears the consequence or who has the right to challenge its use.

The artefacts and experiments behind these questions remain private and in development. This public-safe version is the hypothesis and the questions; it is not evidence of a production implementation. The next useful step is to test the envelope against bounded scenarios: research delegation, reversible operational actions and cross-domain agent discovery. The model needs to fail in visible ways before it deserves stronger claims.

A trust decision, not a trust label

The design goal is not to stamp agents as trusted or untrusted. It is to make each reliance decision explicit enough to inspect: identity, authority, task, evidence, controls and exit.

Authentication remains essential. So do authorisation and the security disciplines enterprises already depend on. Agent-to-agent trust begins by respecting those foundations, then adds the context needed when software can interpret, delegate and act over time.

If this model is useful, it will make autonomy less theatrical and more operational. Not because the system promises to be trustworthy, but because another person can see why it was relied on, what it was allowed to do, what evidence it produced and how to stop it when the conditions change.

This proposed model is part of the broader work on the Workbench. For the operating history behind it, read From racks to agents.