AI Agent Governance: Identity, Audits, and Approvals

An internal agent is usually trusted long before it's governable. It has a vendor login, a persistent browser session, an inbox for verification messages, and perhaps a TOTP authenticator. The team knows what the agent was supposed to do, but often can't prove which identity performed each action, which credential was used, or who could revoke access when the agent crossed a boundary.

That gap defines the practical problem of AI agent governance. Traditional IAM still matters, but it mostly governs identities and resources an organization controls. Production agents also operate on third-party websites, where cookies, accounts, inboxes, and MFA state sit outside the company's directory and SSO perimeter. Governance has to follow the agent into those systems.

Table of Contents

• The Production Problem Governance Has to Solve
• What AI Agent Governance Actually Means
  • Identity becomes a durable principal
  • Authentication crosses the company boundary
  • Authorization moves from roles to capabilities
  • Auditing includes decisions and side effects
• Why Traditional IAM Is Not Enough
• Runtime Controls for Agent Identity and Access
  • Durable identity
  • Origin-scoped credentials
  • TOTP and MFA handling
  • Human approval at the point of risk
• Audit Trails, Lineage, and Incident Response
  • Turn evidence into a response procedure
• Governing Agents Across Multi-Tenant Deployments
• Open Questions in Governing External Agent Identity
• A Production-Ready Governance Checklist

The Production Problem Governance Has to Solve

An invoice-status agent starts with a narrow assignment: sign in to a vendor portal, locate an invoice, read its status, and return the result. After a prompt change, the same agent begins navigating through the portal's administrative area and exports a customer list. Nobody explicitly granted that capability. The agent found a path that appeared useful to its changed objective.

Several controls failed at once. The agent held a long-lived vendor login with broad cookies, so the portal treated it like an established user. The vendor changed its interface between sessions, shifting buttons and navigation paths. The platform recorded that a browser session existed, but it didn't enforce the difference between “read invoice status” and “export customer data.”

That's the core governance failure. Provisioning an identity once isn't the same as controlling every action that identity takes later.

Practical rule: Treat every browser action as a policy decision, not as an implementation detail.

The EU AI Act makes this operational concern a board-level issue in major markets. It entered into force on 1 August 2024, and by 2 August 2026, the majority of its rules became applicable, including enforcement for general-purpose AI models, prohibitions, transparency rules, and AI literacy obligations. Serious violations can result in penalties of up to €35 million or 7% of global annual turnover, whichever is higher, according to the EU AI Act implementation timeline.

For an agent acting on a vendor site, governance therefore needs to answer more than “who created this workflow?” It must establish which durable principal is operating, what site and account it may access, which action it requested, whether the action stayed within scope, and whether a human must approve it before execution.

What AI Agent Governance Actually Means

AI agent governance is the combination of policies, runtime controls, and evidence that keeps an autonomous system within its intended scope. A governed agent has an attributable identity, constrained capabilities, reviewable decisions, and a way to stop or revoke it when conditions change.

The familiar IAM model remains useful, but each concept needs an extension for autonomous software.

Identity becomes a durable principal

A human account usually persists across browser sessions, devices, and application launches. An agent needs the same continuity. Assigning a durable agent identifier lets operators connect activity across model changes, orchestration restarts, browser sessions, and external services. A recycled service account loses that distinction, especially when several agents share its credentials.

Authentication crosses the company boundary

SSO works well when an organization controls the application and the identity provider relationship. External agents often face vendor login pages, email verification, browser-held cookies, CAPTCHA challenges provided by the underlying browser service, and TOTP, which is one specific form of MFA.

The authentication layer should mediate those steps without exposing raw passwords or TOTP seeds to the model. Security guidance for non-human identities recommends keeping secrets server-side, binding them to an origin, and recording which identity used which credential on which origin. Non-human identity security guidance explains why model access to raw secrets increases exposure to prompt injection, trace logging, and context leakage.

Authorization moves from roles to capabilities

RBAC answers which role may access a resource. Agents also need action-level limits. A capability might permit reading invoice status on an approved vendor domain while denying exports, account changes, payments, or access to unrelated administrative screens.

Auditing includes decisions and side effects

An access log that says an agent opened a portal is insufficient. Governance evidence should connect the agent identity, target origin, requested action, credential use, tool result, approval decision, and external side effect. Human approval acts as a runtime override for consequential actions that conventional IAM often permits after initial provisioning.

A 2026 survey found that only 27% of enterprises with production AI agents had deployed formal governance infrastructure, while ungoverned deployments experienced a first recordable compliance incident in an average of 47 days, as reported in the AI agent governance timeline reference. The numbers point to an implementation gap, not a shortage of policy language.

Why Traditional IAM Is Not Enough

Traditional IAM assumes a principal exists in your directory, credentials are issued through systems you manage, and the protected resource sits behind a trust boundary such as SSO. External-agent governance starts with different conditions. The principal is software, the account may belong to the agent on a vendor site, and the resource may be a portal, inbox, or SaaS application your organization doesn't control.

SCIM can provision a user into a supported application, but it won't necessarily create or manage an independent agent-owned account on a vendor website. SAML can federate authentication where the vendor supports your identity provider, but it doesn't govern a persistent browser profile or an account that was created outside that federation.

RBAC also leaves a gap. A role might authorize access to a vendor application, while the agent still needs a narrower rule that blocks exports, limits approved domains, or requires a reviewer before changing account settings. Revocation is similarly incomplete when the organization can disable its own token but can't directly invalidate a third-party cookie or recover an inbox used for account recovery.

The answer isn't to replace IAM. It's to add primitives above it: durable external principals, origin-scoped secrets, isolated browser state, action-level authorization, and lifecycle-aware revocation.

Runtime Controls for Agent Identity and Access

Runtime governance works best as a set of controls that reinforce one another. If the identity is durable but the session is unrestricted, attribution exists without containment. If credentials are scoped but approvals aren't recorded, the team can limit access but can't reconstruct why a sensitive action occurred.

Durable identity

Give each long-lived agent its own principal rather than recycling a shared service account. The identity should remain stable across runs and be associated with the external accounts it uses, including its inbox, browser profile, credentials, and authenticator state.

This creates a reliable ownership boundary. When an agent touches a vendor portal, the audit record can identify the agent, tenant, workflow, and external account without inferring ownership from a process name or a shared API key. A practical machine identity management model provides the foundation for that continuity.

Origin-scoped credentials

A credential should be usable only for the approved origin and intended operation. Before filling a password or TOTP value, the system should verify the live browser origin. If the domain doesn't match the allow-list, the fill should be rejected and recorded. Agent identity guidance also recommends logging credential and authenticator use without recording secret values.

Third-party pages can contain injected instructions, redirects, or UI changes. A model may interpret a page as part of its task, but the credential layer should make the wrong destination technically unusable.

TOTP and MFA handling

TOTP is a time-based code generated from an enrolled authenticator secret. The agent can complete a permitted login flow, but it shouldn't receive the seed or a reusable recovery code. Keep the authenticator material in a protected system, generate the code server-side, and expose only the controlled fill operation.

Some MFA challenges won't fit this pattern. Push approvals, hardware keys, and vendor-specific device checks may require a human or a provider-supported browser capability. Governance should represent that interruption explicitly instead of treating every MFA method as interchangeable.

Human approval at the point of risk

Approval should happen before an irreversible action, not after a notification. The reviewer needs enough context to make a decision: the agent identity, target site, requested action, affected resource, relevant policy, and expected side effect.

Security research recommends workflow-bound tokens, strict tool scopes, sandboxing, continuous authorization, and per-action approval because agentic systems can turn credential misuse or tool abuse into broader unauthorized access. Research on agentic AI security controls connects reusable credentials and tokens with the risk of cross-workflow propagation.

Audit Trails, Lineage, and Incident Response

Governance becomes useful during an incident only when the evidence is detailed enough to reconstruct the decision. An append-only activity record should be keyed by the agent identity and include the target origin, requested action, relevant parameters, policy decision, tool result, and approval outcome.

Lineage adds the missing context. It connects the outbound action to the prompt, retrieved content, tool calls, policy version, and approval event that produced it. Store the record so investigators can search it and detect tampering. Retention should match the obligations of the system and its customers, especially where regulated business processes are involved.

A browser event should show that the agent opened a page or submitted a form. A credential event should show which identity was used and on which origin. An approval event should show who authorized the action and under which policy. Secret values themselves should never appear in the log.

Turn evidence into a response procedure

An incident runbook should be executable under pressure:

• Freeze access: Disable the agent's credential fills, browser sessions, authenticators, and connected account actions.
• Replay activity: Review the agent's recent tool calls, browser events, email events, and policy evaluations.
• Identify spread: Check whether the same credential, cookie, inbox, or OAuth grant was used in another workflow.
• Contain externally: Contact the affected vendor and revoke or reset the external account where possible.
• Record ownership: Notify the human owner, tenant administrator, and security team with an evidence-backed timeline.

Compliance monitoring tools for agent activity can help organize this evidence layer, but monitoring alone isn't enforcement. The system must be able to stop credential use and require approval before a risky side effect occurs.

Governing Agents Across Multi-Tenant Deployments

A SaaS platform can build one agent capability and deploy it for many customers against the same vendor. The implementation may be shared, but the identity lifecycle can't be. Each tenant needs its own namespace, browser profile, inbox, credentials, authenticators, approvals, and audit history.

Suppose a platform provisions customer-support agents for separate tenants. The control plane should create a tenant-scoped agent identity during onboarding, bind it to that tenant's policy bundle, and ensure that browser state and email events remain inside the tenant boundary. Offboarding must revoke the external credentials and sessions the agent used, not just delete an internal database row.

Isolation is a governance property, not only a hosting property.

The platform still owns common controls such as policy templates, provisioning logic, rate-limit handling, and fleet monitoring. Tenant administrators should own the data and external accounts their agents operate. The system needs both boundaries at once.

A shared browser profile is convenient during prototyping and dangerous in production. One tenant's session can expose another tenant's account, and a revocation intended for one customer can disrupt unrelated work. Service account management guidance is relevant here because agent identities need ownership, lifecycle controls, and clear separation rather than a single undifferentiated machine principal.

Open Questions in Governing External Agent Identity

Governance becomes less settled when the agent operates beyond the organization's boundary. The unresolved questions are concrete.

Who owns the MFA factor when a vendor sends a push notification? If an agent uses an inbox for triage and account recovery, can the security team revoke that mailbox, or only the operator who created it? If a browser cookie is shared between a human and an automation, which actor is accountable for an off-policy purchase?

Prompt injection makes the boundary harder. A third-party page can contain text that redirects the agent's next step, while the operator has no certificate authority proving that the page's instructions are trustworthy or unchanged. Origin checks can prevent a password from being filled on the wrong domain, but they don't by themselves establish that every instruction on an approved domain is safe.

The industry is beginning to treat agent governance as a distinct security area. OWASP's agentic AI security and governance materials frame agent-specific risks separately from conventional application security, while broader governance guidance highlights traceability, coordination, vulnerabilities, and loss of human agency.

A 2026 survey cited in trade coverage found that only 21% of organizations had a well-established governance framework for autonomous agents, according to PwC's discussion of AI agents and workforce governance. That gap reflects an operational problem: teams have principles, but many still lack lifecycle controls for external accounts, browser state, inboxes, and MFA.

A Production-Ready Governance Checklist

Before an agent touches a third-party site, test each control rather than documenting it as an aspiration.

• Durable identity: Assign a stable principal tied to one agent, tenant, and owner.
• Origin-scoped credentials: Keep passwords, API keys, cookies, and TOTP material out of model context and reject mismatched origins.
• Capability allow-list: Define permitted domains, actions, data classes, and tools.
• Approval thresholds: Require a human decision before payments, deletions, account changes, exports, or other irreversible actions.
• Append-only evidence: Capture actor, intent, policy version, action, result, credential use, and approval without storing secrets.
• Revocation runbook: Cover credentials, browser profiles, inboxes, authenticators, sessions, and OAuth grants.
• Tenant isolation: Separate identities, email, browser state, credentials, approvals, and audit history for every customer.
• Operational review: Run access reviews and incident exercises so credential compromise and scope drift aren't first encountered during a real event.

Persistent browser state needs its own policy. A persistent profile preserves cookies, localStorage, and other browser-held state between runs, allowing an agent to return to an authenticated account later. The profile should belong to one workspace, not circulate among unrelated agents or tenants, as described in persistent browser identity guidance.

A minimal durable workspace combines profile storage, encrypted credential storage, and a TOTP module that generates codes when MFA is required. Sessions can be created with a credential namespace and persistProfile: true, then released so the profile can be reused later, while expected origins and request-body logging restrictions limit unnecessary exposure, as described in browser session management guidance.

Agentstead provides durable external identity infrastructure for agents, combining persistent browser profiles, inboxes, credentials, TOTP authenticators, approvals, and append-only activity history in isolated workspaces. If your agents need governed access to third-party accounts across runs, visit Agentstead to evaluate the workspace model for your production architecture.