The agent trust and control stack

The first enterprise question about an agent is often framed as identity:

How do we know which agent is acting?

It is an important question. It is not the complete question.

An authenticated agent can still be unauthorised for the action it attempts. An authorised agent can still use the wrong evidence, exceed a policy, misunderstand an exception or produce an outcome nobody can later reconstruct.

Identity tells a system what presented a credential.

Enterprise trust requires considerably more.

Trust is a chain, not a badge

Consider a finance agent instructed to investigate supplier invoices and release eligible payments.

The organisation must establish:

• which agent instance performed the work;
• which legal entity and business owner it represented;
• which invoice, supplier and payment account were in scope;
• which policies and approval limits applied;
• which evidence the agent used;
• whether the supplier and bank details were verified;
• when human approval was required;
• which action was taken;
• whether the ledger and payment records agree;
• how the action can be stopped, reversed or investigated.

No single identity token supplies those answers.

They are produced by a connected control stack.

The ten layers of the control stack

Layer 1: Inventory

An organisation cannot control agents it cannot identify.

The inventory should record:

• agent name and unique identifier;
• business purpose;
• owner and technical custodian;
• vendor, model and runtime;
• connected tools and data sources;
• credentials and service accounts;
• permitted actions;
• risk classification;
• deployment environment;
• current version and last material change;
• status: development, pilot, production, suspended or retired.

The inventory must extend beyond centrally approved agent platforms. Agents may appear inside SaaS products, developer tools, automated workflows and employee-built systems.

The control objective is not a perfect spreadsheet. It is the ability to answer: Which software actors can currently take consequential action in our environment?

Layer 2: Principal and ownership

Every consequential agent must have a principal and an accountable owner.

The principal may be a person, team or legal entity. The owner is responsible for the business outcome and authority delegated to the system. The technical custodian may operate the platform, but should not silently inherit accountability for the commercial or regulatory decision.

Ownership records should answer:

• Who requested this agent?
• Who benefits from its work?
• Who can approve greater authority?
• Who reviews performance and incidents?
• Who can suspend it?
• Who accepts the residual risk?

“The AI team owns it” is usually insufficient.

Layer 3: Identity and credentials

The agent needs a reliable way to authenticate to systems and, where relevant, to counterparties.

This layer includes:

• workload or service identity;
• credentials for tools and APIs;
• binding between agent, principal and organisation;
• credential scope, rotation and expiry;
• attestation about the software or environment;
• discoverable capability descriptions where agents interact across systems.

A2A uses Agent Cards to describe an agent’s identity, capabilities, skills and interaction requirements. MCP provides an open protocol for connecting AI applications to tools and data. These mechanisms help systems interact; organisations still need to decide which cards, servers and credentials they trust. A2A concepts, MCP specification

Layer 4: Delegated authority

Authority answers what the agent may do on behalf of the principal.

Good authority is:

• specific — tied to actions and resources;
• bounded — limited by value, time, geography, counterparty or risk;
• contextual — different rules apply to different situations;
• revocable — access can be reduced or removed quickly;
• expiring — temporary authority does not persist by accident;
• inspectable — a reviewer can see what was delegated and by whom.

Examples:

• issue a refund up to £100 for orders within policy;
• book meetings only inside approved calendar windows;
• purchase usage-based data services up to £500 per month;
• propose contract changes but never accept non-standard terms;
• update opportunity fields but never mark an opportunity closed-won;
• communicate with approved customer segments but never with suppressed contacts.

The correct unit of authority is not “access to Salesforce” or “access to the bank”. It is an action within a defined mandate.

Layer 5: Policy decision and enforcement

Policies translate business, security and regulatory requirements into rules that can shape agent behaviour.

A policy system may consider:

• agent identity;
• principal;
• requested action;
• target resource;
• data classification;
• value and financial limit;
• counterparty status;
• geography;
• time;
• confidence or risk signal;
• prior actions in the workflow;
• required approval.

Decision and enforcement are different.

A policy engine can decide that an action is not allowed. An enforcement point must stop the tool call, transaction or system change. Controls that exist only in the prompt should not be treated as hard permission boundaries.

Layer 6: Evidence and provenance

Consequential decisions should carry the evidence on which they were based.

Useful provenance records:

• data sources consulted;
• source timestamps and versions;
• retrieved passages or structured records;
• instructions and policy versions;
• model and tool versions;
• material intermediate decisions;
• confidence or uncertainty where available;
• human input or overrides.

The objective is not to store every token indefinitely. It is to preserve enough evidence to understand and challenge the action.

Without provenance, an audit log can show that an agent acted without explaining why.

Layer 7: Approval and escalation

Human approval should be designed around risk and ambiguity—not inserted as a ceremonial click.

An approval request should tell the reviewer:

• what the agent proposes;
• why it proposes it;
• which evidence supports it;
• which policy triggered review;
• the financial, customer or legal consequence;
• the available alternatives;
• what will happen after approval;
• how long the approval remains valid.

Escalation is broader than approval. The agent may encounter missing data, conflicting policies, a new counterparty, a high-value customer or a request outside its capability.

The escalation route must reach a person capable of making the decision, not merely the nearest available operator.

Layer 8: Observation and evaluation

Observation answers what the agent did. Evaluation answers whether it was good enough.

The system should capture:

• task and session traces;
• tool calls and state changes;
• policy decisions;
• human interventions;
• latency and cost;
• failures, retries and fallbacks;
• outcome and acceptance;
• changes in behaviour after updates.

Evaluation should operate at several levels:

1. 1.Component: Did retrieval, classification or tool use work?
2. 2.Trajectory: Did the agent take a sensible path through the task?
3. 3.Policy: Did the action remain within authority and rules?
4. 4.Outcome: Did the work create the required business result?
5. 5.Economics: Did it do so at an acceptable total cost?

Static pre-deployment tests are necessary and insufficient. Production data must feed continuing evaluation.

Layer 9: Record, audit and investigation

An enterprise-grade record should allow an authorised reviewer to reconstruct:

• the mandate in force;
• the agent and principal;
• the instruction received;
• the evidence used;
• the policy decisions made;
• approvals and overrides;
• the actions completed;
• the result and downstream records;
• any incident, correction or reversal.

Tamper resistance and retention should reflect the consequence of the workflow. Not every internal productivity task requires the same record as a financial transaction or customer commitment.

Audit should not mean producing a large trace no human can interpret. The most useful systems will create a concise action narrative linked to deeper technical evidence.

Layer 10: Revocation, recovery and recourse

Trust depends on what happens after failure.

Organisations need the ability to:

• suspend an agent;
• revoke credentials and mandates;
• stop in-flight activity where possible;
• identify affected systems and counterparties;
• correct records;
• reverse or compensate eligible actions;
• preserve evidence;
• notify relevant owners;
• change policy and retest;
• resolve disputes.

An agent with strong prevention and no recovery remains an incomplete operating system.

The control loop

Present this as a rendered circular or stepped diagram, not an ASCII graphic:

1. 1.Define the job
2. 2.Assign the owner
3. 3.Grant bounded authority
4. 4.Enforce policy
5. 5.Observe action
6. 6.Evaluate outcome
7. 7.Approve, correct or stop
8. 8.Update authority and tests

Diagram caption: Trust is maintained through a loop. Authority should expand, remain or contract according to evidence.

Four common design mistakes

Mistake 1: Treating the prompt as the permission system

“Never spend more than £1,000” is a useful instruction. It is not equivalent to a payment rail that technically prevents a larger transaction.

Use prompts to guide behaviour and enforcement controls to set hard boundaries.

Mistake 2: Giving the agent a human user’s credentials

Shared or borrowed credentials make ownership, scope and investigation harder. Use distinct workload identity and permissions wherever the underlying system supports it.

Mistake 3: Logging everything but evaluating nothing

A trace can be complete and still fail to answer whether the result was correct, compliant or valuable. Connect observation to explicit acceptance criteria.

Mistake 4: Expanding autonomy before understanding exceptions

The normal path often looks impressive. Production difficulty concentrates in incomplete information, conflicting instructions and cases that do not fit the workflow.

Authority should expand only after the exception pattern is visible.

How the emerging standards fit

MCP: tool and context connection

MCP standardises interactions between AI applications and external tools or data. Enterprise control questions remain around server trust, authentication, authorisation, tool provenance, policy and monitoring. MCP specification

A2A: agent interaction and delegation

A2A provides a common model through which independent agents can discover capabilities and exchange tasks. Enterprise use still needs identity assurance, authority, evidence, commercial terms and cross-party recourse. A2A specification

UCP: commerce lifecycle

UCP provides common commerce capabilities across shopping and order flows. It reduces integration fragmentation but does not replace a buyer’s governance and mandate design. UCP overview

AP2: payment mandates

AP2 uses mandates to provide evidence of user instructions and intended transactions across agents, merchants and payment systems. The practical questions will include issuer acceptance, liability, dispute handling and integration into enterprise approval. AP2

x402: request-native payment

x402 allows an HTTP resource to quote and receive payment within the request flow. It is particularly relevant to paid APIs, data and machine-consumed services. Enterprise buyers will still need wallets/accounts, spending policy, counterparty controls and reconciliation. x402

A practical control baseline

Before a consequential agent enters production, require at least:

1. 1.A named business owner.
2. 2.A defined job and acceptance criterion.
3. 3.An inventory record.
4. 4.Distinct identity and credentials where possible.
5. 5.Documented data and tool access.
6. 6.Bounded authority.
7. 7.Hard enforcement for material limits.
8. 8.Tested escalation and kill path.
9. 9.Pre-deployment replay or simulation.
10. 10.Production observation linked to outcomes.
11. 11.A record sufficient for investigation.
12. 12.A review date and change-control process.

Higher-risk workflows require more: separation of duties, formal approval, legal analysis, continuous security monitoring, independent validation and recovery procedures.

Where commercial value may accumulate

The control stack creates several potential systems of value:

• agent inventories that become systems of record;
• authority graphs connecting principals, agents, tools and actions;
• policy gateways controlling agent access to enterprise systems;
• evidence layers preserving provenance and mandate;
• evaluation platforms connecting traces to outcomes;
• approval interfaces optimised for agent-generated decisions;
• forensic replay and incident-recovery systems;
• cross-company trust, credential and reputation networks;
• procurement systems for external agent capabilities;
• financial controls and sub-ledgers for agent spending.

Large platforms will absorb parts of this stack. Independent companies can still win where neutrality, cross-platform control, regulated workflows or network trust matter.

Conclusion

The enterprise question is not whether an agent can be trusted in the abstract.

It is whether a specific agent, acting for a known principal, can perform a defined job with bounded authority, observable behaviour, sufficient evidence and a credible path to recovery.

Trust is not a model characteristic.

It is an operating system around the model.