AI Agent Identity Governance: Why Runtime Authorization Matters

Key takeaway: An AI agent is a non-human identity with delegated authority, not a user account with a clever interface. Safe deployment requires runtime authorization, least privilege, and an auditable action ledger.

The control problem is no longer theoretical

AI agents are moving from chat interfaces into the operating layer of the enterprise. They query customer systems, open tickets, change cloud configuration, send messages, approve routine work, and call other agents. That shift creates a security question that ordinary application access reviews do not answer: which digital identity is acting, on whose authority, with which exact permission, and why was that permission valid for this action?

VentureBeat reported a sharp gap between confidence and evidence: 85% of IT professionals said every AI agent had a named owner, but only 42% said ownership was actually clear. The difference is not a minor documentation defect. An agent with no accountable owner can keep its credentials after a project ends, inherit an overly broad service account, or continue making decisions after its business context has changed.

Cloud Security Alliance describes agents as categorically different from earlier assistants because they plan, select tools, execute multi-step tasks, and adapt to feedback. In a Vietnamese enterprise, the same pattern appears when an agent connects CRM, accounting, email, and internal knowledge bases. A successful pilot therefore needs more than a model evaluation: it needs an identity and authorization design that can be inspected at runtime.

1. Treat every agent as a first-class non-human identity

An agent should never be represented only by the human who created it or by a shared API key. Create a durable identity record for each deployed agent and record its owner, business purpose, environment, model family, tools, data domains, risk tier, and expiry date. If an orchestrator can create sub-agents, each child should receive a separate identity linked to its parent rather than silently inheriting the parent’s full access.

The identity record should answer five operational questions: who is accountable, what task is permitted, what data is in scope, which tools may be called, and what happens when the owner leaves. These fields belong in the same operational system as service accounts and secrets, not in a slide deck. Ownership also needs a backup team, because an agent that cannot be reviewed during an incident is effectively unowned.

Use stable identifiers in logs, not display names such as “support bot.” A useful event should say agent_id, parent_agent_id, human_subject, tenant, purpose, tool, resource, decision, policy version, and timestamp. This makes an agent’s behavior queryable across cloud accounts and vendors.

2. Separate delegated identity from human identity

An agent often acts for a person, but it is not that person. The authorization decision must preserve both identities: the human or business process that requested the work and the agent that technically executed it. This is the difference between “Khang sent an email” and “agent A, delegated by Khang for ticket triage, sent an email using template B.” The second statement is auditable.

Delegation should be explicit, scoped, and short-lived. Bind a token to a subject, purpose, audience, and maximum duration. Do not allow an agent to turn one approved request into an open-ended session. If a task changes from reading an invoice to paying it, require a new authorization decision because the impact has changed.

For multi-agent systems, propagate the chain of delegation. The downstream research agent should know that it was called by the claims orchestrator, which was called by a workflow run, which was approved by a human role. Without that chain, incident responders cannot distinguish an intended cascade from a compromised agent spawning work.

3. Move from deploy-time approval to runtime authorization

Pre-deployment review remains useful, but it is not enough. A quarterly review cannot observe an agent that acts every second, encounters new content, or receives a changed data set. Runtime authorization places a policy decision point between the agent and each meaningful action. The policy evaluates the current identity, request, resource, context, risk, and history before allowing, denying, or escalating.

For read operations, the policy may permit a narrow data class and redact fields. For writes, external communication, money movement, destructive changes, or privilege escalation, the default should be deny or human approval. The important design choice is per-action authorization rather than a single session-level permission. A valid token proves who is calling; it does not prove that every next action is appropriate.

Keep authorization decisions explainable. Store the rule, policy version, inputs, result, reason, and approval reference. When a customer asks why an automated refund was issued, the business should be able to reconstruct the decision without asking the model to explain itself.

4. Apply least privilege to tools, data, and side effects

Least privilege for agents is more granular than assigning a role such as “sales administrator.” Define an allowlist of tools and operations: read order status, create a draft response, update a low-risk field, or submit a request for approval. Separate observation from mutation, and mutation from irreversible side effects.

Use field-level and row-level controls for sensitive information. An invoice-processing agent may need vendor name and total but not a national identification number. A support agent may need a ticket history but not every customer’s account. In Vietnam, data residency, personal-data protection, and sector rules can make this separation a business requirement as well as a security best practice.

Prefer ephemeral credentials minted for a single task. Rotate secrets automatically, prohibit standing administrator keys, and enforce audience and expiry checks at the gateway. If a tool cannot express narrow permissions, place it behind a broker that can. “The model was told not to do that” is not an access control.

5. Build an action ledger, not just application logs

An agent trace should capture intent, plan revisions, tool calls, retrieved sources, inputs and outputs where lawful, authorization decisions, human approvals, and resulting changes. Store hashes or references for large payloads and apply privacy controls, but do not discard the causal chain. A dashboard that only shows latency and token usage cannot answer a security question.

Alert on behavior, not only failed authentication. Examples include a sudden increase in tools, access to a new data class, repeated denied actions, unusual hours, rapid traversal across tenants, creation of child agents, or an attempt to modify its own policy. Baselines should be specific to the agent’s purpose; a batch reconciliation agent naturally looks different from a customer-support agent.

Run regular access recertification from the ledger. Owners should review what the agent actually touched, not what the original design document promised. This closes the gap between declared governance and runtime reality.

6. Design containment before granting autonomy

Every production agent needs a kill switch, token revocation path, tool-level circuit breaker, and rollback procedure. Containment should work even if the model is hallucinating, the orchestrator is unavailable, or an attacker has influenced the prompt. Disable credentials at the policy layer and preserve evidence before deleting the agent.

Use graduated responses. A low-risk anomaly can trigger extra logging; repeated policy violations can reduce the tool set; a high-impact action can pause the workflow and require a human. The response playbook should name the owner, security contact, business approver, and communication path. Test it with tabletop exercises and controlled fault injection.

An agent must not be able to approve its own exception, edit the policy that governs it, or erase its action history. Administrative separation is essential when an agent can write code, change infrastructure, or manage identity.

A practical 30-day implementation plan

In week one, inventory agents, connectors, service accounts, owners, and data domains. Include shadow agents embedded in SaaS products and development environments. Mark unknown ownership as a risk, not as “pending.” In week two, assign durable identities and replace shared keys with short-lived credentials for the highest-risk workflows.

In week three, introduce a gateway for tool calls and implement four decisions: allow, deny, redact, and require approval. Start with high-impact actions such as sending external email, changing production configuration, exporting personal data, and moving money. In week four, connect the action ledger to incident response, run a simulated compromise, and publish measurable controls.

Metrics should include percentage of agents with an accountable owner, percentage using ephemeral credentials, percentage of actions covered by runtime authorization, time to revoke, denied-action rate, approval latency, and the number of unreviewed privileged paths. These measures reveal whether governance is operating, not merely documented.

Deploy-time review versus runtime governance

The two layers are complementary. Deployment review establishes a safe starting point; runtime governance prevents that starting point from becoming permanent authority. Enterprises should make runtime coverage a release criterion for any agent that can access sensitive data or create external side effects.

Frequently Asked Questions

Why is an agent identity different from a service account?

A service account usually represents an application or process with relatively stable permissions. An agent plans and adapts, may delegate work, and can cause side effects through many tools. Its identity therefore needs purpose, delegation chain, runtime context, and action-level authorization in addition to a credential.

Is human approval required for every agent action?

No. Low-risk, reversible actions can be automated when policy and monitoring are strong. Human approval should be required for high-impact actions such as money movement, external commitments, destructive changes, sensitive-data export, or privilege changes. The threshold must be explicit and enforced by a gateway.

What should a small Vietnamese company implement first?

Start with an inventory, named owners, separate identities, short-lived credentials, and a narrow tool gateway. Choose one workflow with meaningful risk, log every action, and test revocation. Do not begin by trying to govern every model equally; begin with the paths that can change systems or expose personal data.

How do runtime controls help with prompt injection?

Runtime controls assume that instructions and retrieved content can be hostile. Even if an agent is manipulated, the gateway can deny a tool, redact data, require approval, or stop the credential. This does not eliminate prompt injection, but it limits the blast radius and creates evidence for response.

What is the most important governance metric?

There is no single metric, but runtime authorization coverage is a strong starting point: what percentage of meaningful agent actions pass through an enforceable decision point? Pair it with owner coverage, time to revoke, privileged-path review, and tested containment.

The operating model behind trustworthy autonomy

Technology alone will not close the identity gap. Security, platform engineering, data owners, legal and the business process owner need a shared operating model. The business owner defines the acceptable outcome and impact level; security defines non-negotiable controls; platform teams implement the policy enforcement point; and data owners define classification and retention. This division prevents a common failure mode in which everyone assumes another team is responsible for the agent.

Start with a small policy vocabulary that every team can understand: identity, purpose, scope, tool, resource, approval and expiry. Map those terms to the existing IAM, API gateway, SIEM and ticketing systems instead of creating a parallel governance island. Review exceptions as measurable risk decisions with an owner and sunset date. When an agent changes model, connector or business purpose, treat that as a new authorization event, not a harmless configuration edit.

Trustworthy autonomy is therefore an operational capability. It is earned through narrow permissions, evidence of correct behavior and the ability to stop quickly. An organization that can answer who acted, what was allowed, what changed and how to revoke access is in a far stronger position than one that simply has a policy saying humans remain responsible.

Sources

• VentureBeat — 85% of IT teams claim every AI agent is under control
• Cloud Security Alliance — The AI Agent Governance Gap
• AvePoint — Why 9 in 10 Organizations Delay AI Deployment

Read the Vietnamese edition: https://agoobi.com/blog/vi/quan-tri-danh-tinh-agent-ai-uy-quyen-thoi-gian-thuc/