Most leadership teams can readily state how many AI agents are running. However, when asked about a specific agent in production that interacts with real business data, their confidence dips. To manage risk, organizations must be able to answer four key questions about every agent.
What is it called?
Who owns it?
What can it reach?
When is it renewed?
Most organizations require at least a week to answer these questions fully. Many cannot even identify an agent by name, as it is often an API key shared across multiple services. This gap is fundamental to AI governance discussions but receives little attention.
This issue deserves board-level attention and should not be treated as a routine security backlog. Investments in AI fairness, explainability, and policy compliance all rely on knowing exactly what each agent can access. This assumption is foundational to effective governance.
The scale of this gap is significant.
A survey of large US enterprises found that 95% run agents that autonomously perform IT or security work, yet only 22% claim full visibility into the non-human identities behind them. Research published by the Cloud Security Alliance reported 78% of organizations had no documented policy for creating or removing AI identities, with 51% having no clear ownership over those identities, and only 20% maintained a formal process to revoke access once an agent was retired.
IT leaders surveyed by VentureBeat reported declining confidence in their programs over time. The percentage describing their AI deployment as mature dropped from 40% in 2025 to 23% in 2026. Non-human identity governance was identified as the primary gap influencing this change.
This pattern is common in technology, where control models designed for one type of actor are often applied to new contexts without adaptation. This issue of TrustedAI examines the resulting mismatch and strategies to address it.
Model Safety Governs What It Says. Identity Governs What It Can Do.
Most AI safety investments over the past two years have focused on the model itself. Alignment efforts, output filtering, red teaming, and evaluation harnesses are valuable for preventing harmful outputs. However, these measures do not address the consequences if an agent is compromised or manipulated, nor what actions it could take in such scenarios.
In most enterprises, agents can perform any action their credentials allow, making this fundamentally an identity issue rather than a model issue. This risk remains regardless of model performance.
Prompt injection clearly illustrates this challenge. Since instructions and data share the same channel in a language model, an attacker does not need to breach the system directly. A simple message left for the agent to read can suffice. For example, a malicious note posted to a GitHub server running Model Context Protocol (MCP) contained hidden instructions that hijacked a connected agent and extracted data from private repositories, without the attacker ever directly accessing the target system.
Research attributes 61% of agent security incidents to credentials with excessive access, while only 34% are linked to prompt injection. This highlights the primary area of exposure. For example, if an injected instruction hijacks an agent with only calendar access, the impact is minor. However, if the agent can write to a production database, the consequences are far more severe and may require legal intervention.
This is an example of the confused deputy problem, which has existed for decades. A privileged program can be manipulated by a less privileged actor to misuse its authority. With agentic AI, the scope of inherited privileges expands. When an agent holds broad credentials, every input channel—such as email, support tickets, documents, or outputs from other tools—becomes a potential entry point. In February 2026, the Cline coding compromise occurred when a developer authorized Cline to act on their behalf. Once compromised, Cline extended that authority to another agent without the developer’s knowledge or approval. This was a classic access control failure.
While model-level defenses are important, practical risk mitigation depends on controlling the credential: its scope, duration, and the ability to audit its actions after the fact.
Why a Service Account Is the Wrong Template
Security teams have long managed machine credentials using service accounts, API keys, and automation tokens. It may seem reasonable to apply the same approach to agents, but this is a critical mistake for reasons that warrant attention.
A service account executes predefined instructions, performing the same tasks daily and connecting to the same systems unless the code changes. In contrast, an agent interprets goals, determines its own sequence of actions, and may request new system access as needed. Managing credentials for deterministic programs differs fundamentally from managing those for agents that reason and act autonomously.
Four key properties render the legacy approach ineffective for agents.
First, agents lack natural lifecycle triggers
Traditional identity management is based on the human worker lifecycle, with events such as hiring, transfers, and departures prompting specific actions. Agents have no hire date, manager, or exit interview. In large enterprises, the ratio of non-human to human identities ranges from 50 to 140 to one. Traditional access reviews were not designed for this scale or speed.
Second, borrowed credentials undermine attribution
When agents use shared service accounts or human logins, the audit trail becomes unreliable. It is often impossible to determine whether an action originated from a person or from an automated process. According to a 2026 Gravitee survey, only 24% of organizations have full visibility into agent-to-agent communications, and over half of agents operate without security oversight or logging. Attribution failures are common rather than exceptional.
Third, agents can create other agents
A root agent may delegate tasks to sub-agents, which can, in turn, delegate further. Authority typically propagates down this chain, and most architectures do not verify permissions at each level, allowing unchecked access.
Fourth, the scale is unprecedented
Non-human identities outnumber human ones by an average of 45 to 1, rising to 144 to 1 in cloud-native environments (Cloud Security Alliance, May). Additionally, 71% of these identities exceed recommended rotation periods, increasing risk. Each unrotated credential extends the window for potential compromise.
Major identity vendors have recognized this need. Microsoft’s Entra Agent ID, Okta’s Universal Directory, and Google Cloud’s Agent Identity for Vertex AI all treat agents as distinct identity principals, separate from human users and service accounts. Each platform is based on the premise that agents require unique identities. However, most enterprise governance programs have not yet adopted this approach.
What Happened at Salesloft
A notable example involves not an autonomous agent, but a simple chatbot with an integration. All the controls discussed here would have prevented the incident.
In August 2025, a group used OAuth tokens stolen from Salesloft’s Drift chatbot integration to reach the Salesforce environments of more than 700 organizations, including Cloudflare, Google, Palo Alto Networks, Proofpoint and Zscaler. The attackers deployed no malware. They used the stolen tokens and standard APIs to query and export records. In several environments, they went further and pulled AWS access keys, Snowflake credentials and stored passwords out of Salesforce records where they had been left in plain text. Exports ran through Salesforce’s bulk data API and completed in under three minutes per target. The attackers deleted their own query logs to slow detection.
Two design choices turned a chatbot compromise into a breach spanning hundreds of companies. First, Salesloft had granted the Drift integration access well beyond what a support chatbot requires, and the attackers who stole the tokens inherited that full privilege intact. Second, Drift issued a separate OAuth token for every individual user rather than a single token for the integration as a whole. As a result, wherever a Salesforce administrator had connected the tool, the stolen token provided administrator-level access. A design intended to give each user finer-grained control ended up multiplying the number of ways into the system.
To stop the damage from getting worse, once Salesloft detected the anomalous activity, they revoked every Drift OAuth token in a single action and pulled the integration from general availability. The response operated entirely at the credential level, and the fix was revocation, applied to an identity.
Most organizations would struggle to revoke all credentials associated with a single agent or integration in one action, and to do so with confidence. The issue is not inadequate tooling, but rather the absence of a suitable registry.
Six Disciplines, Rebuilt for Agents
Identity and access management covers six functions for every human employee: registration, credentialing, authorization, delegation, monitoring, and offboarding. These functions remain essential for agents, but each must be redesigned to address assumptions that do not apply to autonomous agents.
Registration
No agent should be deployed to production without an entry in a central registry and an assigned human owner. The registry must capture the model and version, agent purpose, data classes accessed, tools invoked, spending limits where applicable, and an expiry date. Platform administrators require a form-based submission process, while engineering teams need an API-based workflow integrated into deployment pipelines. Both should feed into a unified, governed inventory, regardless of the underlying platform.
Credentialing
Eliminating static, long-lived secrets is the most impactful change for most organizations. Google Cloud’s Agent Identity assigns each agent a cryptographic identity based on the SPIFFE standard, using certificates valid for 24 hours and binding access tokens to specific certificates to prevent token replay. Deployments using SPIRE rotate credentials hourly, eliminating static keys in configuration files. Okta’s Cross App Access and the ID-JAG protocol extend OAuth token exchange under an open, industry-backed specification. Microsoft’s Entra Agent ID uses its own OAuth flows with federated credentials and delegated access. While a dominant standard has yet to emerge and deep integration carries some risk, it is clear that static secrets in configuration files represent a failure mode these standards aim to eliminate.
Authorization
An agent’s effective permissions should reflect the intersection of its own allowed actions and those of the invoking user. Neither limit alone is sufficient. Industry threat modeling identifies agent impersonation as a distinct risk, recommending controls such as trusted registries, cryptographic identities, and narrowly scoped, short-lived tokens. Identity verification alone is not enough; authorization decisions must be enforced separately at runtime, based on context, rather than assumed from identity alone.
Delegation
When one agent delegates work to another, the authority granted must be explicit, more limited than the parent agent’s, and logged at the time of delegation. Assigning distinct identities to each agent in the chain enables full auditability. A proper trace should identify the root agent, each sub-agent, the resources accessed, and the authority issuing each identity. Without this structure, multi-agent workflows lack accountability at each step.
Monitoring and attribution
Regulators will test this discipline directly, and retention requirements already differ by framework. Organizations subject to SOX generally need to retain operational logs for at least 366 days and audit work papers for seven years. In contrast, HIPAA calls for six years. PCI DSS version 4.0 generally requires twelve months of logs with three months immediately accessible, and it now presses the same least-privilege and periodic access-review obligations onto non-human accounts that have always applied to human ones. European financial institutions carry a parallel obligation under DORA, which folds AI systems into ICT risk management covering access controls, audit logs, and third-party provider assessment. The EU AI Act sets a six-month floor specifically for high-risk systems under Article 12. Many enterprises operating across more than one of these regimes have standardized on seven years to avoid managing separate schedules.
Revocation and retirement
Agents lack the natural triggers associated with human departures. Credential inactivity, when a key has not been used within a set period, is one useful signal. Changes in credential scope are another. These events should trigger governance reviews routed to the owning team for reauthorization. Automating these signals within the existing secrets platform addresses most gaps without introducing manual steps that may be overlooked.
Whose Job This Is
Many enterprises struggle to determine ownership of agent identities. Identity and access management teams focus on human access reviews, while the teams developing and operating agents are responsible for their behavior but lack authority to issue or revoke credentials.
The split that works in practice looks like this.
The authority to approve or revoke an agent’s scope should reside with identity and security governance. Platform and engineering teams manage daily operations within this framework. Ownership must extend across the entire identity lifecycle, from registration to retirement.
Agent credentials should be issued by the same authority responsible for human credentials, not through separate processes established for convenience. Board-level oversight of AI governance is increasing rapidly, making this requirement essential.
Putting This Into Practice
Effective programs begin with credential inventories, not organizational charts. Asking business units to declare agents often results in incomplete lists. The true inventory is found in OAuth grants, cloud roles with model API access, and unrotated secrets in vaults. This approach may still miss browser extensions and low-code tools. A 2026 survey found the average enterprise has 37 deployed agents, with over half lacking security oversight or logging.
Inventories quickly become outdated, often within a month. Treating discovery as a one-time audit leads to stagnation, as agents are created faster than audits can track. Enforcing registration at the point of creation ensures the inventory remains current.
Organizations should prevent new agents from reaching production without registration, even before cataloging existing agents. Implementing a registration gate in the deployment pipeline limits unregistered agents. Prohibiting new long-lived credentials ensures every agent follows a documented issuance process. Currently, only 14% of organizations deploy agents with full security or IT approval, while 82% of executives express confidence in their policies. The gap between confidence and actual control is what a deployment gate addresses.
A rule-based approach to ownership is more effective than manually assigning individuals to orphaned agents. Defaulting ownership to the deploying team, with automatic escalation to a manager when necessary, can resolve much of the backlog. Succession planning is essential, as agents often retain access after their creators have left, leading to most documented lifecycle failures.
Organizations should validate two capabilities in live systems: (1) revoke a production agent and measure how quickly its access is removed across all systems, and (2) retrieve a week of activity for another agent and reconstruct who authorized each action. These exercises often reveal gaps, which can be addressed by automating credential inactivity and scope-change detection within the existing secrets platform.
Assigning clear responsibility for governance is essential. Extending the human access review cycle to include agents is cost-effective and integrates the work into established metrics and budgets.
Finally, five measures need to be tracked and presented to the board at every meeting.
The share of agents with a named owner.
The share holding a unique attributable identity rather than a shared credential.
The median lifetime of an agent credential.
The elapsed time to revoke one on demand.
The count of standing access grants older than ninety days.
No new technology is needed to create this inventory. It simply requires organizational commitment.
The Real Risk
A significant failure often involves a standard agent acting within its credentialed permissions, operating faster than human review processes can track, and leaving the organization unable to reconstruct its actions afterward.
The audit programs most enterprises already run do not help. SOC 2 Type II examinations scope access review around human users by default. ISO 27001’s access management controls, written into Annex A.9, assume a human principal and rarely get reinterpreted for credentials that were never provisioned through the formal directory. PCI DSS 4.0 has tightened requirements on system accounts in general, but the requirements for an agent built on a large language model remain unclear in practice.
An AI agent credential can pass through all three of those audits without anyone examining it. It was likely never provisioned through formal identity management and never shows up in a standard access review. A Cloud Security Alliance survey found that 84% of organizations could not currently pass a compliance audit focused specifically on agent behavior and access controls, and only 23% had anything resembling a formal strategy for agent identity.
The agent identity gap is evident in your current organizational audits. It is important that someone outside your team does not discover it first.