Your finance team just built an AI agent that reads open journals, checks reconciliations, and drafts comments on outstanding items. The demo was flawless. Then someone asked a simple question: Who actually performed this action?
Was the agent acting on behalf of a specific controller? Or as an independent system? And if the result is wrong, who is accountable?
That question stops teams cold. It’s not a technical detail. It cuts to the heart of how an organization views an AI agent: as an anonymous helper, or as a digital actor that deserves the same identity, permissions, and auditability as any human or application.
Many organizations are already advanced in thinking about models, prompts, and API integrations. But when use cases move from demo to production, one thing is consistently overlooked: the agent has no clear identity. It runs on a generic service account with overly broad permissions and logs that can’t explain the origin of its actions. The moment an agent reads an invoice, opens a ticket, changes an order status, or triggers a procurement workflow, the company can’t answer basic questions: What identity did the agent use? On whose behalf did it act? What permissions did it have? And in what workflow context did the action occur?
For an enterprise, this is not a small detail. Without an explicit identity and access model, auditability, accountability, and runtime governance collapse exactly when the agent starts delivering real value.
The operating model for agent identity and access: from source of mandate through delegation and permission levels to runtime execution and audit.
The Agent Is Not an Anonymous Script
In traditional enterprise architecture, we recognize several types of actors: humans, applications, service accounts, and scheduled processes. Agentic AI adds a new category: a digital actor that can reason, choose tools, and act across multiple steps. An agent should not be treated like an anonymous script running in the background.
An agent needs a clear identity because the enterprise needs to know three things: who performed the action, under whose mandate, and in what workflow. Without these three, enterprise control becomes fuzzy.
Consider a procurement agent that receives an intake request, checks a contract, and drafts a purchase request in the ERP. If that action is logged only as activity from a generic service account, then when a problem occurs, the company can’t tell whether the action was triggered by a specific user, part of a scheduled workflow, an autonomous event, or an access abuse. The same applies in finance close, customer operations, or IT operations. When an agent starts touching business state, its identity must be as traceable as any human or application.
Identity also forms the foundation of accountability. In the old operating model, accountability followed the human: analyst, approver, supervisor, system owner. In the agentic model, some actions shift to digital labor. That doesn’t mean accountability disappears. On the contrary, it must be made more explicit. The company needs to answer: Which function does this agent belong to? Who is the business owner? Who is the technical owner? What tools are allowed? What are the boundaries of permitted action? Without this, the organization faces a dangerous situation: the agent acts with real consequences, but no control model matches its impact.
Identity also determines trust boundaries. An agent interacting with internal employees is different from one serving external customers. An agent that only reads a knowledge base is different from one that can change payment status. An agent running in a verified user context is different from one serving a public channel. If all agents are treated the same, the company tends to fall into two extremes: too loose or too restrictive. Both are bad.
Static Roles Are Not Enough for Agent Permissions
Once the agent has an identity, the harder question is authorization. Many teams make an old mistake in a new form: they grant a static role and hope it is enough.
For agents, permissions need context. Is the agent acting for a specific user, a scheduled workflow, or an event trigger? Is it reading data, drafting a recommendation, executing a change, or supporting approval? Is the data general business information or sensitive payroll, vendor banking, contract, or customer data?
The same agent may be allowed to read invoice data, draft a mismatch explanation, and recommend a resolution, but not release a payment block. An HR agent may answer onboarding questions and draft notifications, but not change compensation or employment status. Context-aware authorization is what prevents a useful pilot from becoming an over-permissioned production risk.
Delegated Authority: On Whose Behalf Does the Agent Act?
Many agent actions do not truly belong to the agent. They come from a mandate: a user instruction, an approved workflow, or an autonomous event trigger.
Those sources must be distinguishable. A procurement agent drafting a purchase request for a buyer is different from a finance close agent running a scheduled nightly check, and both are different from an IT operations agent responding to a monitoring event. The audit trail should capture the source of authority, the agent identity, the validity period, the tools used, and whether the action stayed within policy.
Delegation should also be bounded: revocable, time-bound, scope-bound, and sometimes value-bound. The agent may draft standard purchase requests up to a threshold, send low-risk customer follow-ups, or run limited diagnostics. Outside that mandate, it should stop.
Implementation Patterns for the Enterprise
The enterprise pattern is simpler than it first appears: give every production agent its own service identity, bind tool calls to a policy engine, separate permissions by action type, and log the full chain of action.
That means an agent should not share a generic service account. It should be registered with a business owner, technical owner, process domain, allowed tools, risk tier, and lifecycle status. Runtime access should be evaluated every time the agent calls a tool, not only when the session begins.
The most useful permission model is layered: read, recommend, draft, execute, and approve. A finance agent may read journals, recommend treatments, and draft commentary; execution may be limited to low-risk actions; material approval should remain human. A procurement agent may read contracts and draft purchase requests, but approval rights should stay with accountable approvers.
The audit trail must explain more than the final API call. It should connect the user or mandate source, the agent identity, the policy decision, the tool call, the input, the output, approvals, and the final state change. If the company cannot reconstruct that chain, the agent is not ready for production scale.
What This Means in Practice
Here’s how this translates to your next sprint:
- Register each agent as a first-class identity in your IAM system, with a business owner and technical owner.
- Separate permissions by action type: read, recommend, draft, execute, approve. Don’t give an agent write access because it needs read access.
- Bind tool calls to a policy engine at runtime, not just at session start. Evaluate every API call against the current context.
- Log the full delegation chain: who or what triggered the action, what mandate was active, what tools were used, and what state changed.
- Make delegation bounded: time-bound, scope-bound, and revocable. An agent should not hold permanent authority.
- Test revocation in incident drills. Can you disable an agent’s access in under 60 seconds?
If your team is still using a shared service account for multiple agents, or if permissions are granted broadly to “make it work,” these are the first things to fix.
When This Pattern Is Not Yet Right
Not every organization is ready to apply a mature model immediately. There are several danger signals that indicate an agent is not yet ready to scale:
- The agent still uses a shared service account without a unique identity.
- Permissions are given too broadly just to make the use case work.
- There is no separation between rights to read, draft, and execute.
- Delegated authority is not explicitly recorded.
- Tool calls do not pass through a policy engine or runtime control.
- Audit logs only record the final output, not the decision chain.
- There is no quick way to revoke agent access in an incident.
- The business owner does not know exactly what tools and data the agent uses.
If several of these symptoms are present, scaling agentic AI will increase risk faster than value.
Agents with execution autonomy are also not yet appropriate for domains that touch material transactions without clear rollback, where policy definitions cannot yet be translated into runtime rules, where data is not stable, or where process ownership is still unclear. In such conditions, it is safer to start with read, recommend, and draft while strengthening identity, policy, and logging first.
Questions to Take Home
The practical test is straightforward. If tomorrow an auditor, regulator, or risk committee asks, “Who performed this action, under whose mandate, and why did the system allow it?” can your company answer with evidence?
If the answer is not yet clear, the next priority is not a more capable model. It is the identity, authorization, delegation, and audit model that lets an AI agent become a trustworthy enterprise actor.
This article was originally published on ariefwara.github.io.
Top comments (0)