An AI Agent Is Not a Service Account

Hypothetical incident: a procurement bot books the whole catalogue

A procurement assistant is launched to triage inbound purchase requests and raise orders in the ERP. It is introduced on a tight deadline. To keep integration simple, the team reuses an existing service account with broad procurement permissions. The agent runs unattended, reads email, matches stock codes, checks supplier terms and raises orders.

Two weeks later, audit flags multiple orders that breach delegated authority. The agent approved items outside category policy and placed direct awards without competition. It renewed vendor contracts with outdated pricing. It also changed supplier bank details during a data “fix” routine, which auto‑approved in the finance system. Operations now face supplier disputes, clawbacks and a forensic effort to understand what happened.

This is a hypothetical scenario. It is plausible because the agent had the wrong identity and the wrong authority model. It had no named sponsor. Its permissions were flat. Its credentials were long‑lived. Its autonomy level was not declared or enforced. Its evidence was a mixture of chat traces, prompt fragments and tool logs, none of which alone tells a clean story.

Agentic AI increases the attack surface, creates pathways for privilege creep and behavioural misalignment, and can obscure event records if left indistinct from human and workload activity. That is the judgement in the secure adoption guidance from the US Cybersecurity and Infrastructure Security Agency and partners. The same guidance advises avoiding broad or unrestricted access and starting with low‑risk, non‑sensitive use cases while controls mature (CISA (opens in a new tab)).

The lesson is simple. An AI agent is not a service account. It is a dynamic system that can act autonomously or on behalf of users. Its identity, authority and evidence must be defined before it touches systems of record.

Why human and service identities fail for agents

Enterprises have two mature identity archetypes.

• Human identities represent people. They carry HR‑centred lifecycle, multifactor authentication, device trust, and delegated authority norms. They bind activity to an accountable person.
• Service identities represent workloads. They are used for non‑interactive code paths, integration jobs and background tasks. They favour reliability, stable credentials, and broad permissions that span environments or tenants.

Agents inherit neither cleanly.

Human identities assume a persistent person with accountability, presence and employment lifecycle events. An agent is not a person. It cannot accept a policy briefing, complete annual ethics training, or be disciplined. A human identity bound to an agent can blur accountability or break processes like step‑up approvals.

Service identities assume a static workload with known behaviours. An agent is adaptive. It can plan, chain tools and respond to novel context. It may operate with different autonomy levels over a day. A service identity with generalised permissions is an attack path when given to an adaptive system.

Agents therefore need identities that encode different semantics. Microsoft’s guidance on agent identities highlights the need to distinguish agent operations from human and workload identities, to right‑size access, and to support dynamic creation and retirement as agents are spawned and retired (Microsoft Entra (opens in a new tab)). That is an architectural point, not a product dependency. The label on the directory object is less important than the controls and governance attached to it.

The table below compares the three identity types.

A service account alone does not encode sponsor, mandate, autonomy or evidence. That is why it fails for agents.

For a fuller foundation on authority models, see the Agent Authority insight, and Agentic AI Patterns for an introduction to agentic systems.

The three operating modes: autonomous, delegated, supervised

Agents do not run in one uniform mode. Their controls and identity semantics should reflect the operating posture.

• Autonomous mode. The agent plans and acts within a bounded mandate without human in the loop. It is suitable for low‑risk, non‑sensitive tasks with strong rollback and evidence. This aligns with the CISA recommendation to begin with constrained, low‑risk scopes while controls mature (CISA (opens in a new tab)).

• Delegated mode. The agent acts explicitly on behalf of a named user. It uses user authority as a delegation, often with proof of delegation embedded in the token or session. The evidence trail must carry both the agent identity and the delegating user identity, with clear scoping and expiry. Step‑up approvals can be required based on action type or value.

• Supervised mode. The agent proposes actions and a human approves or amends them. The authority remains with the human; the agent’s identity is still required to separate its operations, record provenance and cap access to read operations and dry‑run write simulations where possible.

Each mode benefits from being declared at registration, enforced at runtime and logged at decision points. The same agent may run across modes for different tasks. The identity must carry mode metadata to drive policy. If a helpdesk agent answers routine queries autonomously, it should not be able to trigger refunds without entering a delegated or supervised path with additional checks.

An authority lifecycle that fits how agents work

Agents need an explicit authority lifecycle. It must be lightweight enough to operate at software speed, while asserting the right sponsorship, approvals and constraints.

Register

• Create an agent record with a stable identifier, named business sponsor, technical owner, and risk classification.
• Declare the operating mode(s), mandate, intended tools, systems of record, data domains and environments.
• Define scope constraints: permitted actions, value limits, jurisdictions, time‑of‑day windows, concurrency caps and budget thresholds.
• Provide an evidence plan: what artefacts will be captured to reconstruct decisions, including prompts, tool calls, inputs and outputs.
• Propose an identity plan: dedicated agent identity namespace, token lifetime, rotation policy, session binding, and delegation semantics if acting for users.

Approve

• Route to the appropriate approvers based on risk classification, systems touched and data sensitivity.
• Perform a dry‑run assessment in a non‑production environment with realistic, masked data.
• Verify least‑privilege scopes against the stated mandate and mode. Avoid broad or unrestricted access as per CISA’s guidance (CISA (opens in a new tab)).
• Confirm that revocation paths, kill switches and anomaly alerts are wired.

Operate

• Issue short‑lived credentials to the agent identity. Bind tokens to audience, tools and session context. Rotate automatically.
• Enforce policy at multiple choke points: identity provider, tool broker, API gateway, data access layer and within the agent runtime.
• Capture evidence continuously. Log every tool call with inputs, decisions, origin (user vs agent), model/runtime version and outputs. Hash and timestamp where practicable.
• Apply autonomy guards. Enforce concurrency caps, value limits, and escalation triggers. Require approvals for sensitive actions.
• Enable simulation and “dry run” paths for write operations. Use them by default in supervised mode.

Review

• Periodically review actual behaviour against mandate. Sample evidence trails. Verify that actions stayed within scope and that autonomy guards worked.
• Rotate sponsors and technical owners through attestations. Renew approvals on a cadence appropriate to risk.
• Compare privilege use to granted scopes. Remove unused capabilities. Watch for privilege creep and mode drift.
• Inspect prompt and memory content. Purge or mask retained context according to policy.

Revoke

• Provide an immediate kill switch. Disable the agent identity. Revoke tokens and invalidate sessions.
• Revoke delegated authorities for named users if delegation was abused or expired.
• Preserve evidence. Ensure that logs and artefacts are retained for the required period for forensic and regulatory purposes.
• Conduct post‑incident review and update registration templates, policies and tool configurations.

A lifecycle like this fits with an agent identity model designed for dynamic creation and retirement, as described by Microsoft’s Entra guidance (Microsoft Entra (opens in a new tab)). Again, architecture and governance matter more than whether your directory has a first‑class “agent” object type.

For the authority concepts in depth, see the Agent Authority insight.

Controls at the identity, tool and data layers

A resilient design distributes guardrails. No single layer is sufficient. Agentic AI can chain capabilities in unanticipated ways. Defence in depth reduces blast radius.

Identity layer

• Dedicated agent identities. Use a distinct namespace or label to separate agent operations from human and general service identities. This is consistent with Microsoft’s guidance to distinguish agent identities for right‑sized access and dynamic lifecycle (Microsoft Entra (opens in a new tab)).
• Short‑lived credentials. Mint tokens with tight time‑to‑live and audience restrictions. Prefer signed assertions to long‑lived secrets. Automate rotation.
• Just‑in‑time privilege. Grant roles or scopes only when needed, bound to the specific session or task, then drop them.
• Delegation semantics. When acting for a user, carry both identities. Embed the delegation evidence in the token. Limit duration and scope.
• Step‑up and approvals. Require additional factors or approvals for sensitive actions, value thresholds, or when operating out of normal bounds.
• Concurrency and budget caps. Limit active sessions, requests per minute, and spend per window per agent identity.
• Origin preservation. Propagate origin attributes end‑to‑end: who initiated, under which mode, for which mandate.

Tool layer

• Tool registry and broker. Maintain a catalogue of tools with capability descriptors, input/output schemas, side‑effects, and required scopes. Mediate access through a broker that enforces policy and logs usage. Model Context Protocol (MCP) is one practical way to describe and mediate tools across runtimes; see the Model Context Protocol explainer.
• Pre‑conditions and post‑conditions. Declare checks for tool invocation and effects. For example, do not allow “change supplier bank account” without recent counter‑party verification.
• Simulation paths. Provide dry‑run interfaces for tools that mutate state. Default to simulation in supervised mode.
• Value and scope guards. At the broker, enforce value limits, categories, and environment separation. Reject calls that exceed mandate or cross environments.
• Kill switches. Allow tool‑level and agent‑level shutdowns, with audit of who triggered them and why.
• Model/runtimes as tools. Treat the underlying model, memory store and planning component as tools in the registry. Version and pin them. Log their use.

Data layer

• Policy‑mediated retrieval. Interpose a retrieval layer with policy enforcement. Do not hand wide dataframes to agents. Return minimum necessary slices with masking where required.
• Row/column‑level controls. Respect data classifications and implement field‑level controls for personal or sensitive attributes. Avoid free‑text dumps of sensitive records into prompts.
• Redaction and tokenisation. For agents that must see reference patterns, provide redacted or tokenised views where feasible.
• Taints and labels. Tag data retrieved or produced by agents. Prevent agent‑sourced outputs from silently re‑entering training or decision pipelines without review.
• Test data discipline. Use realistic but masked datasets for development and simulation to avoid privacy breaches and leakage into prompts or memory.
• Outbox and reconciliation. For critical writes to systems of record, queue in an outbox for a gatekeeper service to validate and post. Record reconciliation outcomes.

Evidence layer

• Structured event model. Standardise how prompts, tool calls, inputs, outputs, origins, decisions and approvals are logged. Include hashes and timestamps to detect tampering.
• Provenance capture. Keep the linkage between a user request, agent plan, tools used and final state change. This enables reconstructed narratives in audit or incident response.
• Version tracking. Record model and tool versions, policy snapshots and environment identifiers.
• Retention and access. Align retention to regulatory obligations. Restrict access to evidence to authorised roles with oversight.

Together, these layers form a practical spine to contain risk while enabling useful work.

For the interplay with API gateways and caller identity, see API Security When the Caller Is an AI Agent.

The first 30 days for a CTO or CISO

The goal in the first month is to create clarity, contain risk and set a cadence. Focus on a small number of visible, low‑risk wins and on the baseline controls that will scale.

• Establish a registration pattern. Create a lightweight form for agent registration: sponsor, mandate, mode, tools, systems, data domains, scope constraints, evidence plan, kill switch owner. Make it the single entry point.
• Define the modes. Publish definitions of autonomous, delegated and supervised modes. Map each to default controls, approval paths and evidence requirements.
• Choose a pilot. Select one low‑risk, non‑sensitive use case as per CISA guidance. Examples include knowledge base retrieval with masking, IT self‑service requests that never write to systems of record, or invoice triage that only labels and routes (CISA (opens in a new tab)).
• Stand up agent identities. In your identity provider, define a convention for agent identities with short‑lived tokens, audience binding and labels for sponsor and mode. Follow Microsoft’s guidance to distinguish agent operations and to enable dynamic creation and retirement (Microsoft Entra (opens in a new tab)). Do not wait for a new product label; use existing constructs if they can encode the semantics.
• Implement least privilege. Create minimal scopes and roles for the pilot. Remove wildcard permissions. Test in non‑production with masked data.
• Build the tool registry. Catalogue the tools the pilot will use. Define their descriptors, side‑effects and pre‑/post‑conditions. Route calls through a broker that can enforce policy and log usage. If you are adopting MCP, this is the place to anchor it; see the Model Context Protocol explainer.
• Wire the evidence pipeline. Decide what you will log and where. Capture prompts, tool calls, inputs, outputs, origins, decisions, approvals and versions. Store with integrity checks and retention policy.
• Add kill switches. Ensure you can disable the agent identity and its tools quickly. Test the path. Assign on‑call ownership.
• Set concurrency and budgets. Cap sessions, requests and spend for the pilot. Tune based on observation.
• Run a tabletop. Walk through misuse and failure modes: prompt injection, tool misuse, runaway loops, unexpected delegation, data leakage. Check detection and response steps. Use the CISA risks as prompts: attack surface, privilege creep, behavioural misalignment, obscured events (CISA (opens in a new tab)).
• Integrate with change and risk. Add the agent registration to change advisory. Agree risk acceptance templates for sponsors. Tie reviews to quarterly cycles.
• Update joiner/mover/leaver. Add sponsor responsibilities. If a sponsor leaves, trigger review or revoke for their agents.
• Train the basics. Brief product and platform teams on modes, registration, least privilege, evidence expectations and kill switch use. Keep it short and pragmatic.
• Publish a roadmap. Signal that broader capabilities will follow: delegated mode with token‑level delegation proof, supervised workflows with UI approval, outbox patterns for writes, data masking for retrieval.

Anchor the governance in delivery. Keep friction low but consistent. The point is to make safe behaviour the easiest path.

For the broader governance framing, see AI Governance Is Enforcement, Not Intent.

Architecture and governance over labels

It is tempting to wait for a perfect “agent identity” object in your directory or to buy a new tool to manage agents. That delays safety and value. The core requirements are architectural and governance‑led:

• Separate agent operations from human and generic service activity in identity, logs and approvals.
• Tie every agent to a named sponsor and a bounded mandate.
• Keep privileges narrow, short‑lived and just‑in‑time.
• Declare and enforce autonomy levels.
• Capture reconstructable evidence.

If your existing identity platform can enforce these properties, use it. Where gaps exist, compensate at the tool and data layers. You can adopt MCP to make tool exposure and policy more predictable across runtimes. You can use your API gateway to pin scopes to tools and reject broad access. You can build an evidence pipeline today.

Over time, you can standardise names and processes, and you may choose to adopt first‑class agent identity primitives as they mature in your chosen platform. Microsoft’s articulation of agent identities is a useful direction of travel because it encodes the dynamic and distinct nature of agent operations (Microsoft Entra (opens in a new tab)). But the essential separation, scoping and evidence can be delivered now, independent of branding.

Applying the model to refunds and procurement

Return to the procurement and refund domain. These are systems of record with financial impact and supplier relationships at stake. They are not the place to start with unconstrained autonomy.

• For invoice triage, use supervised mode. Let the agent classify, extract and propose coding. A human approves. The agent identity has read access and simulation rights only.
• For catalogue ordering within a framework agreement, autonomous mode can work. Cap order value, category, supplier and quantity. Use an outbox for posting. The agent identity can only create draft orders below thresholds.
• For refunds, delegated mode is suitable. A customer service adviser delegates a refund action to the agent within their own limits. The token carries both identities and the policy caps the amount and reason codes. Step‑up approval is required for edge cases.
• For vendor master data changes, keep agents in read‑only mode. Allow proposals only. Changes require supervised approval with multi‑person review.

Across these cases, the same identity, authority and evidence principles apply. You do not reuse a broad service account. You do not blend agent actions into a human identity. You separate, bound and observe.

Common objections and practical responses

• “We already have service accounts.” Keep them for deterministic workloads. For agents, introduce a distinct identity convention with short‑lived tokens and mode metadata. Narrow scopes per agent. It is an incremental change that pays back in control and evidence.

• “We do not want another directory object class.” You do not need one to start. Use existing app registrations or workload identities, tagged and governed as “agent”. Add the sponsorship, mandate and mode to your registration process and policy engine.

• “Evidence is in the chat logs.” Chat history is incomplete. You need tool call logs, inputs, outputs, decisions, approvals and model/runtime versions. Define a structured event model and capture it near the tools and gateways, not just in chat.

• “It slows us down.” The registration form, least‑privilege scopes and evidence pipeline are quick to define and reuse. They enable more autonomy safely. They also reduce incident time when something does go wrong.

These responses keep the focus on architecture and governance rather than product labels.

Closing takeaway

Treat agents as first‑class actors with their own identity, authority and evidence. Separate them from people and from static services. Keep mandates bounded, privileges narrow and credentials short‑lived. Declare autonomy. Capture provenance. Start small, as CISA advises, and scale with discipline. The cost is modest. The risk reduction is material.

For broader context, see Agent Authority, Agentic AI Patterns, the Model Context Protocol explainer, API Security When the Caller Is an AI Agent, and AI Governance Is Enforcement, Not Intent.