Why Identity Alone Cannot Govern AI Agents

Identity is the beginning of accountability

AI agent governance needs strong identity. Without it, the enterprise cannot know which person, role, service, workload, agent, or vendor feature was involved in an action. Identity management, authentication, federation, service-account hygiene, access review, and credential protection are foundational controls. NIST digital identity guidance and the NIST Cybersecurity Framework, whose 2.0 revision added Govern as a sixth core function in February 2024, both reinforce how central identity is to modern cybersecurity programmes.

For AI agents, identity becomes even more important because agents often act across systems. An agent may read a document, call an API, update a ticket, send a message, or trigger a workflow. Each step needs attribution. The organisation should be able to tell whether the action was initiated by a person, performed by an agent, executed through a service account, or mediated by a vendor platform.

But beginning is not the same as completion. Identity tells the enterprise who or what acted. It does not automatically explain why the action happened, whether the human was allowed to delegate it, whether the agent stayed within approved scope, whether the data was appropriate, whether review was required, or whether residual risk was accepted. Those are governance questions.

Agents do not fit neatly into user identity

Traditional identity models often assume a direct relationship between a human user and a system action. A user logs in, requests access, performs a transaction, and the system records the event. AI agents complicate that relationship. The human may provide a goal, but the agent may decide the intermediate steps, retrieve context, select tools, generate outputs, and perform actions.

If every agent action is attributed only to the human, the organisation loses visibility into the agent layer. If every action is attributed only to the agent service account, the organisation loses visibility into the human delegation. If a shared service identity is used across several workflows, evidence becomes even weaker. The record needs both human and agent identity, plus the relationship between them.

This is why agent identity should be explicit. The enterprise should know which agent acted, under which version or configuration, for which user or team, inside which workflow, using which tools, and under which approval rules. A governed record should not flatten human and agent activity into one account label.

Authentication does not prove purpose

Authentication proves that an actor has met a defined identity requirement. It may show that a user signed in with a strong authenticator or that a service presented a valid credential. That is necessary for trust. It does not prove that the action was appropriate for the business purpose.

A user may be authenticated and authorised to access customer records. An agent acting for that user may also be technically able to retrieve those records. Governance still needs to decide whether the retrieval fits the approved task, whether the data can be used with a model provider, whether the output can be shared externally, and whether human approval is required before action.

Purpose matters because AI agents combine steps. A permission that is acceptable for one workflow may be unacceptable for another. Reading a document for internal summarisation is different from using it to produce customer advice. Drafting a message is different from sending it. Authentication establishes trust in the actor. Governance establishes whether the actor should perform this action in this context.

Authorisation does not prove delegated authority

Authorisation usually answers whether an identity can access a system, function, object, or API. Agent governance needs a more specific question: was this delegated action authorised for this purpose, with this data, at this autonomy level, under this risk condition? The answer may change even when the underlying permission remains the same.

Consider an agent with permission to create tickets. Creating a low-risk internal task may be acceptable. Creating an incident ticket that triggers an executive notification may require review. Creating a customer-impacting workflow item may need stronger approval. The permission to create a ticket does not carry all of those governance distinctions.

Delegated authority should therefore be governed separately from technical access. The organisation should define which agents can use which tools, what they can do with those tools, whether actions are reversible, what requires approval, and who can expand authority. This is where identity and access management connects to AI governance rather than replacing it.

Service accounts can hide accountability

Many agent systems rely on service accounts, API keys, OAuth applications, or platform integrations. These identities are practical, but they can hide accountability if they are not tied to user intent and governance evidence. A log that shows an agent service account called an API may not show which human initiated the work, which objective was pursued, or which policy allowed the call.

Shared service accounts are especially risky for governance. They may be convenient, but they collapse multiple workflows into one technical identity. If an agent causes an issue, investigators may struggle to distinguish user action, agent action, automated retry, vendor feature, and system integration. The result is a weak evidence trail even if technical access was valid.

A governed service identity should be scoped, traceable, and connected to business context. It should carry or link to the user, agent, workflow, purpose, data class, tool action, policy outcome, approval, and exception state. The technical account should not be the only record of authority.

The excessive agency problem

OWASP lists excessive agency (LLM06:2025) as a major risk in its Top 10 for Large Language Model Applications, attributing it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. Excessive agency appears when a model or agent can perform damaging actions because it has too much capability, too much permission, insufficient oversight, or weak tool boundaries. Identity controls help limit who can use an agent, but they do not fully solve excessive agency.

An authenticated user may ask an agent to do something ambiguous. The agent may interpret the request broadly, call a tool unexpectedly, or act on manipulated context. The agent identity may be valid and the tool permission may be real. The governance question is whether the agent should have had that degree of autonomy for the task.

Reducing excessive agency requires least privilege, but also purpose limitation, action constraints, review gates, output validation, monitoring, and incident response. Identity is one input to those controls. It is not the full control design.

Agent autonomy needs modes, not one permission

AI agents can operate at different autonomy levels. They may observe, draft, recommend, classify, route, create tasks, ask for approval, execute actions, or escalate exceptions. A single permission model can obscure those differences. The enterprise may think an agent is only assisting when it is actually influencing or executing work.

Governance should define autonomy modes clearly. A draft mode may allow the agent to prepare text but not send it. A recommendation mode may allow the agent to suggest an action but require a human to decide. An execution mode may allow limited actions within narrow rules. A high-impact mode may require explicit approval and stronger evidence. These modes should be visible in the control record.

Identity tells the organisation which agent acted. Autonomy mode tells the organisation what kind of authority the agent exercised. Both are needed. A low-risk identity with high autonomy can still create material risk, while a high-trust user may need guardrails when delegating actions to an agent.

Data access does not equal data use permission

Identity and access systems often control whether an actor can read data. AI governance must also control how that data can be used. An agent may have valid access to a repository because it supports the user’s work. That does not automatically mean the agent can include the data in a prompt, send it to a provider, create an embedding, summarise it for another audience, or write derived content into a different system.

This distinction matters for personal information, confidential records, regulated data, trade secrets, security incidents, contracts, source code, and privileged material. Access can be necessary for a task while certain uses remain prohibited. The governance policy should define allowed uses by data class, provider, purpose, retention, external exposure, and human review requirement.

A strong model connects identity to data classification and action. The question is not only whether the agent can read a document. It is whether the agent can use that document for this objective, in this tool, with this model, for this output, under these controls. Identity opens the door. Governance decides what can happen inside the room.

Impersonation and delegation should not be confused

Some agent implementations act as the user. Others act as a separate application with delegated permissions. Both patterns can be valid, but they create different governance needs. If the agent acts as the user, logs may make the action look human even when the agent made intermediate choices. If the agent acts as itself, logs may hide who requested the work unless delegation context is preserved.

Impersonation can be convenient because existing permissions apply. It can also blur accountability. A reviewer may not know which parts of an action came from the human, the agent, or an automated workflow. Delegated application identity can be cleaner, but only if the record binds the agent to the human, purpose, tool, and approval. Neither pattern removes the need for governance evidence.

The organisation should choose identity patterns intentionally. It should document when agents act as users, when they act as applications, when they act through service accounts, and how actions are attributed. This helps investigations, audit, privacy review, and user trust.

Approvals need more than named approvers

Identity can identify an approver, but governance must define what the approver is approving. A human approval is weak if the approver cannot see the agent objective, data used, policy warning, tool action, output, risk tier, and consequence. An approval record that only says a person clicked a button may not be enough for assurance.

Useful approvals are contextual. The approver should understand whether the action is external, reversible, customer-impacting, privacy-relevant, contractual, regulated, or operationally material. They should know whether the agent has changed the output, whether data restrictions applied, and whether an exception is being granted. The approval evidence should show the basis for the decision.

This matters because AI agents can make action feel routine. A user may approve a sequence quickly without noticing that one step changed risk. Governance should make material decisions visible and slow them down only where needed. A name in the log shows who approved. Governance ensures the approval itself was meaningful.

Identity review must include agent authority

Enterprises already perform access reviews for users, privileged accounts, groups, applications, and service accounts. AI agents should be included, but the review should not be limited to whether the account exists. Reviewers should examine what the agent can do, which tools it can call, which data it can reach, which workflows it supports, and which autonomy mode applies.

An access review that only checks group membership may miss an agent that has accumulated broad tool authority. A service identity may be approved for one purpose but reused in another. A vendor feature may inherit permissions from an existing integration. Governance review should ask whether the authority still matches the approved use case.

This review should also examine inactive agents, test agents, prototypes, and vendor features. Unused or forgotten agent identities can become a security risk and a governance risk. The enterprise should remove stale authority, reduce scope, and retain evidence of review decisions.

Group inheritance can create invisible authority

Many access models rely on groups, roles, inherited permissions, and application profiles. That is normal enterprise practice, but it can create invisible agent authority. An agent attached to a team workspace, repository, service desk, or document system may inherit broad access because the integration follows existing group permissions. The agent may then use that inherited access in ways the original group design did not anticipate.

The issue is not that group inheritance is wrong. It is that AI agents can turn inherited read or write access into new forms of action. A group may have access to documents for human collaboration. An agent with the same reach may summarise them, combine them, embed them, quote them, route them, or use them to make recommendations. The original access model may not have considered those transformations.

Governance should therefore review inherited authority at the workflow level. It should ask which groups an agent can act for, which repositories or systems those groups expose, which data classes are involved, and whether the agent can move or transform information across boundaries. Identity review sees the group. Governance review sees the delegated workflow.

Third-party agents complicate attribution

Third-party agents and vendor-embedded AI features make attribution harder. A vendor platform may perform summarisation, classification, routing, or workflow action inside a product the enterprise already uses. The user identity, vendor service identity, model provider, and internal record may all be involved in one action. Identity logs alone may not show the complete chain.

This matters when questions arise about data use, output quality, or responsibility. Did the user request the action? Did the vendor feature run automatically? Was the model provider changed? Was the output based on customer data, internal documents, or user-provided content? Which organisation controls the logs? Which terms govern retention and review? These questions are governance questions that sit on top of identity.

Enterprises should ask vendors how AI actions are attributed and evidenced. The answer should cover user initiation, automated triggers, model or feature changes, data handling, logging, administrative controls, and exportable evidence. A vendor may have strong identity controls while still giving customers limited governance visibility. That limitation should be understood before material use.

Break-glass access needs special handling

Break-glass and emergency access models are common in security and operations. They allow privileged action when normal workflows fail or urgent response is required. AI agents create a new question: should an agent ever be able to invoke, suggest, or operate under break-glass authority, and if so, under what evidence and approval conditions?

In most enterprise settings, emergency authority should be tightly limited. An agent may assist by preparing context, summarising an incident, or recommending a runbook step. Actually using elevated privileges, changing access, altering records, disabling controls, or triggering operational changes should require strong human authority and a clear record. The risk is not only compromise. It is an agent accelerating a harmful action under pressure.

Governance should define emergency boundaries before the emergency. It should specify which agent capabilities are disabled, which require approval, which humans can authorise them, what evidence is captured, and how post-incident review occurs. Identity can identify privileged users. Governance decides whether delegated emergency action is acceptable.

Privilege escalation paths need agent-aware review

Identity teams often review privileged groups, administrative roles, and high-risk applications. Agents add indirect escalation paths. An agent may not be an administrator, but it may be able to open a ticket that requests access, draft a change for approval, trigger a workflow, modify a configuration file, or influence a human operator. Those paths can matter as much as direct privilege.

Agent-aware review looks for chains. Can the agent combine read access, drafting authority, workflow creation, and messaging to produce an elevated outcome? Can it call a low-risk tool that starts a high-risk downstream process? Can it persuade, route, or prepare actions that humans approve too quickly? These questions are not captured by simply asking whether the agent has an admin role.

Governance should document indirect authority and place controls at the point where influence becomes action. That may mean stronger approval, clearer warnings, separation of duties, output validation, or blocked workflows. Identity shows the formal privilege. Governance inspects the practical path to impact.

User consent is not the same as enterprise authority

Some agent workflows rely on user consent. A user connects a mailbox, document store, calendar, repository, or application and authorises the agent to act. Consent can be useful, but it does not automatically mean the enterprise has approved the use case or accepted the risk. A user may have access to data that they are not allowed to use with an AI agent.

This distinction is important for enterprise governance. A user might consent to an agent reading messages to draft replies. The organisation still needs to decide whether customer data, confidential attachments, personal information, legal material, or security content can be processed in that workflow. Consent from the user is only one part of the authority chain.

Governance should define which agent connections are allowed, which scopes are prohibited, which data classes are restricted, and which workflows require business approval. The consent screen tells the user what an application wants. The governance system tells the enterprise whether the requested delegation is appropriate.

Deprovisioning agents is different from disabling users

When a user leaves a company or changes role, identity teams disable accounts, remove group membership, rotate credentials, and review privileged access. AI agents add a second layer. The agent may have stored connections, scheduled tasks, delegated tokens, workflow triggers, cached context, service accounts, or vendor-side configuration that persist beyond the original user relationship.

A strong offboarding process should therefore include agents and AI integrations. Which agents did the user create or administer? Which delegated connections did they authorise? Which workflows depend on their approval? Which service accounts, API tokens, or vendor features were tied to their team? Which evidence records need retention? Disabling the user identity may not disable every delegated AI pathway.

The same logic applies when a project ends or a pilot is retired. Test agents should not keep access forever. Prototype integrations should not remain connected to production data. Governance should require decommissioning evidence: authority removed, tokens revoked, schedules stopped, data retention handled, and owners reassigned or closed.

Audit reconstruction should not depend on memory

When identity is the only strong record, audit reconstruction often depends on memory. A reviewer can see that an account accessed a system, but must ask engineers, product managers, security teams, or business users why the action happened. That may work for small pilots. It does not scale when agents become part of everyday operations.

A mature governance record should let reviewers reconstruct a material action without interviewing everyone involved. It should show the human, agent, workflow, purpose, data class, tool call, policy decision, approval, exception, and final outcome. Interviews may still be useful, but they should clarify evidence rather than replace it.

This is a practical test for identity-based agent governance. If the organisation can identify the actor but cannot explain the delegation, policy decision, and business context, identity is doing its job but governance is incomplete. The remedy is not weaker identity. It is stronger context around identity.

Evidence should bind identity to intent

The most important governance record binds identity to intent. It should show who requested the work, which agent acted, what objective was provided, which data and tools were used, which policy decision occurred, whether approval was required, and what final action happened. This gives reviewers a complete story rather than a sequence of disconnected logs.

Intent does not mean storing private chain-of-thought or exposing sensitive internal reasoning. It means recording the business objective, instruction category, use case, policy context, and decision basis needed for accountability. Organisations should design evidence carefully so it supports review without creating unnecessary privacy, security, or confidentiality exposure.

The record should also preserve failures and blocked actions. If an agent attempted to use restricted data, call a prohibited tool, or act outside scope, that event can reveal policy gaps and training needs. Identity tells which actor was involved. Governance evidence explains what the system attempted and how controls responded.

Conclusion: Helixar perspective

Helixar’s view is that enterprises can connect identity to AI governance by adding operational policy, delegated-authority context, approval rules, and reviewable evidence around AI activity. This framing is useful for questions identity systems do not answer alone: what was the agent trying to do, which policy applied, which data and tools were involved, and why was the action allowed, approved, blocked, or escalated?

For security and identity teams, Helixar can complement identity and access management by preserving agent context, tool boundaries, policy decisions, and intervention signals. For governance, risk, privacy, legal, compliance, audit, and business teams, it helps create a reviewable record that connects human identity, agent identity, purpose, data class, approval, exception, and outcome.

Helixar does not replace identity providers, access management, privileged access management, logging, SIEM, legal advice, privacy review, or business judgement. It supports those controls by making delegated AI action more accountable. The goal is not identity instead of governance. The goal is identity connected to governance.

Mechanically, that connection is what Helixar enforces in the path of the agent. Because the control plane sits in front of or in place of the AI gateway, it intercepts every agent action across every model provider and, at that moment, verifies both the user identity and the agent identity along with the surrounding context. It then evaluates the delegated action against policy, weighing the purpose, data class, tool call, and autonomy mode that authentication and authorisation cannot judge on their own, and applies a graduated response: observe, alert, require approval, block, or contain. Because it is fail-closed by default, an ambiguous or excessive-agency request does not proceed simply because the credential was valid, and organisation-wide cost caps bound runaway activity. Every decision, including blocked and escalated attempts, is written to a tamper-evident, independently verifiable evidence trail and compiled into framework-aligned evidence packs, with SOC 2 and ISO 27001 available today and ISO 42001, EU DORA, PCI DSS v4, APRA CPS 234, RBNZ BS-11, and the NZ Privacy Act 2020 mapped and delivered at implementation.

What leaders should ask

Leaders should ask whether the organisation can distinguish human action from agent action. Can it show which agents exist, which identities they use, which users can delegate work, which systems they can reach, and which actions require approval? Can it prove whether an agent acted as a user, as an application, or through a service account?

They should also ask whether identity is connected to purpose. Can a material agent action be traced from the user to the agent, objective, data, tool, policy decision, approval, exception, and outcome? Can access reviews identify not only accounts, but agent authority and autonomy? Can blocked or escalated actions be reviewed across the portfolio?

The answer should not be that identity solves everything. The answer should be that identity is strong and connected to the governance record. That is the difference between knowing who acted and knowing whether the action was properly governed.