AI agents are infrastructure identities, not assistants with tools

The moment an AI system can read organisational data, invoke tools and continue work without a person approving every step, the architecture problem becomes delegated authority.

A chatbot drafts a response.

An agent sends it.

The difference looks small in the interface. It is large in the infrastructure.

The first system produces content for a person to review. The second may select recipients, read private records, invoke an API, create a ticket, modify a repository or schedule another process.

It no longer sits outside the operating environment.

It acts inside it.

The relevant question is not only whether the model gives good answers. It is whether the organisation can identify the agent, constrain its authority, explain its actions and stop it without losing control of the work already in motion.

The central test

An AI agent should be governed as a delegated infrastructure identity whose permissions, memory, tools, budget and evidence are bounded by the task it has been authorised to perform.

---

The industry is moving from output to action

Generative AI initially entered many organisations through interfaces that returned text, images or code suggestions.

Agentic systems extend the model into a loop.

They interpret a goal, select actions, call tools, observe results and decide what to do next. The loop may continue for minutes or hours and may involve several agents or external systems.

That shift is now reaching standards and security institutions. In early 2026, NIST launched work on software-agent identity and authorisation and announced an AI Agent Standards Initiative focused on secure, interoperable systems capable of acting on behalf of users. (NIST)

This is not simply a new AI feature.

It is a new way of delegating operational authority.

Common mistake

Treating an agent as a chatbot that has been given API access.

Better framing

Treat the model as one decision component inside a controlled execution system. Identity, permissions, tools, state and evidence belong to the surrounding architecture.

The model may propose an action.

The infrastructure decides whether that action is allowed to become real.

An agent is neither a user nor an ordinary service account

Traditional access models distinguish human identities from machine identities.

Humans authenticate, receive roles and perform actions. Service accounts execute predefined software with relatively predictable behaviour.

AI agents sit between those categories.

They act for a person or organisation, but their immediate choices may be generated dynamically. They can reinterpret context, select tools and change plans as new information appears.

Giving an agent a user’s full authority is dangerous because the agent does not share the user’s judgement.

Giving it a broad service account is dangerous because the account may remain active beyond the task and provide no useful connection to the person who delegated the work.

A better model separates the actors.

Human or organisational principal
              |
              v
       Delegation decision
              |
              v
      Agent identity and task
              |
       plan and propose
              |
              v
     Policy enforcement point
              |
      authorise or reject
              |
              v
     Tool-specific executor
              |
              v
     Target system and evidence

The agent should not inherit authority merely because it can describe a valid action.

Authority should be granted at the enforcement point according to the current task, user, target, risk and operating context.

Delegation needs a visible chain

When a person asks an agent to perform work, several identities may become involved.

A user initiates the request. An application hosts the agent. A model produces a plan. One or more tools execute actions. External services process the result. Another agent may continue the chain.

The organisation must be able to reconstruct that delegation.

Who initiated the task? Which agent instance received it? Which model and policy version were active? Which credentials were issued? Which tools were invoked? Which actions required approval? Which result was returned?

Without that chain, an action may be technically attributable to a service account while remaining organisationally unexplained.

A useful delegation record includes:

• the initiating principal
• the authorised objective
• the agent and configuration version
• the permitted tools and data domains
• the maximum duration and cost
• approvals or policy decisions
• each consequential action
• termination and final status

This is not merely for audit.

It allows operators to stop or recover work safely.

An agent that cannot explain the authority under which it is acting should not receive high-impact permissions.

---

Permissions should be issued for the task, not the agent

Permanent agent credentials are convenient.

They are also difficult to govern.

An agent that sometimes reads documentation, sometimes changes infrastructure and sometimes sends messages may accumulate every permission needed for every possible task. Its effective authority becomes broader than any one user intended to delegate.

Task-bound credentials reverse the model.

The system begins with little or no authority. It requests a capability for a specific action. Policy evaluates the request against the delegating principal, task scope, target resource and current conditions. The issued credential is narrow and short-lived.

For example:

Allowed:
- Read documents in project A
- Create a draft change request
- Run tests in a non-production environment
- Valid for 30 minutes

Not allowed:
- Read other projects
- Merge code
- Change production
- Create new credentials
- Extend its own access

The agent may still make a poor decision.

The infrastructure limits what that decision can affect.

This is ordinary least privilege applied to a system whose behaviour is less predictable than traditional automation.

Prompt injection is an authority-boundary failure

An agent may receive instructions from several places:

• the user
• system policy
• retrieved documents
• websites
• emails
• tool descriptions
• another agent
• previous memory

Some of those sources are untrusted.

A document may contain text that looks like an instruction. A web page may tell the agent to reveal information or invoke a tool. An upstream agent may pass corrupted context. A tool description may change after approval.

The model’s difficulty distinguishing data from instructions becomes dangerous when model output can cause privileged action.

NIST’s 2026 work on agent identity explicitly includes auditing, non-repudiation and controls for prompt injection. A subsequent standards initiative also focuses on secure, interoperable AI agents. (NIST)

OWASP’s agentic-security work highlights memory manipulation, tool misuse, identity misconfiguration and attacks that propagate through multi-agent systems. (OWASP Gen AI Security Project)

The solution cannot be “write a stronger prompt”.

Prompts are part of the defence, not the enforcement boundary.

Untrusted content should not be able to grant authority. Tools should validate parameters independently. High-impact actions should pass through deterministic policy and, where appropriate, human approval.

The model can interpret intent.

It should not define its own permissions.

Memory is infrastructure state

Agent memory is often described as a convenience that makes interactions more coherent.

Operationally, it is state.

Memory may contain user preferences, previous decisions, credentials, summaries, retrieved documents, intermediate plans or assumptions about the environment.

That state can become stale, corrupted or poisoned.

A malicious instruction stored during one task may influence another. An incorrect summary may become accepted history. Sensitive information may cross user or project boundaries. A temporary exception may be remembered as permanent policy.

Agent memory therefore needs the controls applied to other stateful systems:

• ownership
• scope
• provenance
• retention
• integrity
• access control
• deletion
• recovery
• versioning where necessary

Not every agent needs durable memory.

Stateless or task-local operation is often safer because it narrows the material that can influence future decisions.

Where durable memory is justified, the system should distinguish:

Policy memory       — approved rules and constraints
Task memory         — state for one bounded piece of work
User memory         — preferences authorised for one principal
Operational memory  — verified facts about systems
Retrieved context   — untrusted or conditionally trusted inputs

Combining all five into one conversation history destroys useful trust boundaries.

---

Tool use should be designed as a transaction

An agent call is frequently implemented as a simple sequence:

1. model selects tool
2. application passes arguments
3. tool executes
4. result returns to model

That is too small for consequential actions.

A stronger execution path treats the tool call as a transaction.

Before execution:

• validate the target and parameters
• confirm the required authority
• check current state
• estimate impact
• determine whether approval is required
• create an action identifier

During execution:

• enforce scope
• prevent credential reuse
• record material steps
• stop on unexpected state

After execution:

• verify the result
• record the changed state
• release or revoke credentials
• update task status
• decide whether further action remains authorised

This pattern also improves failure handling.

An agent may time out after creating a resource but before recording success. Retrying blindly can duplicate the action. A workflow may revoke old access before confirming new access. A sequence may update part of a system and then encounter a policy rejection.

Tool operations should be idempotent where possible and explicit about partial completion where not.

The agent needs to know what happened.

The operator needs to know what remains safe.

Evidence must connect intention to effect

Agent logs often preserve prompts and responses.

That is not enough.

A model may describe an action it did not perform. A tool may complete an action the final response omits. Several internal reasoning steps may be irrelevant to accountability while the actual permission decision is missing.

Operational evidence should connect four things:

1. intention — what objective was delegated
2. authority — what actions were permitted
3. execution — what tools and systems changed
4. effect — what state existed afterward

The organisation should be able to answer:

• Which person or process initiated the work?
• Which agent instance acted?
• Which model, tools and policies were used?
• What data influenced the decision?
• Which action was proposed?
• Which policy or person authorised it?
• What changed?
• Was the result verified?
• What was rolled back or left incomplete?

A transcript is useful evidence of interaction.

It is not a substitute for an attributable operating record.

Cost and energy are also authority limits

An agent can consume resources without changing production systems.

It can loop, retry, retrieve large volumes of data, call several models, generate media or launch other agents. A task that appears to be one request may produce hundreds of model and tool operations.

The IEA’s 2026 analysis notes that reasoning, video and agentic tasks can require much more energy per query than simple text generation. (IEA)

Agents therefore need resource boundaries alongside security boundaries:

• maximum model calls
• maximum tool calls
• time limit
• token or compute budget
• data-retrieval limit
• concurrency limit
• external spending limit
• escalation when the budget is exhausted

A cost limit is not merely a financial safeguard.

It prevents a confused or manipulated agent from turning uncertainty into unbounded infrastructure demand.

The system should not reward persistence without evidence of progress.

---

Recovery means stopping the agent without losing the system

Agentic systems need a controlled stop path.

Disabling the user interface may not be enough. Jobs may remain queued. Tool credentials may still be valid. Child agents may continue. External systems may be waiting for callbacks.

A credible stop procedure should:

1. prevent new delegation
2. revoke task credentials
3. stop or quarantine active executions
4. identify partial actions
5. preserve evidence
6. restore affected state where required
7. confirm that downstream work has stopped

This is the agent equivalent of incident containment.

A global kill switch may be useful, but broad shutdown can interrupt legitimate work and destroy evidence. More precise controls are better: stop one agent, one task, one tool class or one target system.

Recovery should also cover the agent platform itself.

Can the organisation reconstruct policies, tool definitions, memory stores, evaluation sets and identity bindings? Can it verify that a recovered agent behaves like the approved version?

Restoring the model endpoint alone does not restore the service.

A practical agent-control review

Area	Weak signal	Stronger evidence
Identity	The agent uses a service account	Each task has an attributable agent identity and delegating principal
Authority	The agent can access required systems	Short-lived, task-bound capabilities are issued at execution time
Context	The model receives relevant information	Sources are labelled by provenance and trust level
Memory	Conversation history is retained	Memory has scope, ownership, retention and deletion controls
Tools	Tools are listed in configuration	Parameters, target state and policy are validated independently
Approval	A human can review outputs	High-impact actions have explicit approval and expiry conditions
Evidence	Prompts and responses are logged	Intention, authority, execution and resulting state are connected
Failure	The agent can be disabled	Tasks, credentials and partial actions can be contained independently
Resources	Usage is monitored	Time, compute, tool, data and spending budgets are enforced
Transfer	The framework is documented	Another team can inspect, operate, recover and replace the agent system

The table should be applied according to consequence.

An agent that summarises public material does not need the same controls as one that changes identity, infrastructure, finances or research records.

Authority should grow only when evidence of control grows with it.

Agents should extend institutional capability, not obscure it

AI agents can reduce repetitive work and coordinate complex systems.

They can help operators inspect environments, prepare changes, correlate evidence and carry out well-bounded procedures.

Their value disappears when autonomy is treated as permission to bypass architecture.

An ownable agent system keeps the organisation in control of:

• who delegated the work
• what the agent may do
• which information it may trust
• how long it may continue
• what resources it may consume
• which evidence it must preserve
• how it is stopped and replaced

The model can remain probabilistic.

The authority boundary should not be.

AI agents are not employees, and they are not ordinary scripts.

They are delegated infrastructure identities whose actions must remain constrained by systems more predictable than the models making the plan.

One question for the next architecture review

Choose the first agent expected to change a real system and ask:

If the agent misunderstood its objective, consumed malicious context and selected the wrong tool, which independent control would prevent its mistake from becoming an authorised action?