An AI agent cannot call a repository, mailbox or business API without authority. That authority is the security problem to manage.
The term "agent identity crisis" makes this sound mysterious. It is mostly an inventory, authorization and lifecycle problem. The difficult part is that an agent selects actions at runtime, reads untrusted content and can cross several tools during one task.
My basis for this view is previous Microsoft identity-security and security-operations work across more than 40 organizations. I have not scanned those organizations for the agent counts quoted by vendors. Where I use those numbers below, I attribute them to the reporting source.
Start with the correct identity model
Curity makes a useful correction: AI agents are applications. They should remain in machine identity and access management, and they can use established mechanisms such as workload identities, OAuth, OpenID Connect, JWT-based credentials and client certificates.
That does not mean an agent should disappear inside a generic service-account inventory. Mark it as an agent so policy can reflect delegation, changing tool paths and exposure to prompt injection. Keep human and machine identities separate.
A minimum identity record should contain:
| Field | Required answer |
|---|---|
| Agent ID | Which exact runtime is acting? |
| Human owner | Who approves access and receives review requests? |
| Technical owner | Who can disable or repair it? |
| Purpose | Which task justifies the access? |
| Environment | Development, test or production? |
| Tools and APIs | Which actions can it invoke? |
| Data classes | Which sensitive data can it read or write? |
| Credential type | Workload identity, OAuth token, API key or certificate? |
| Granted scopes | What is the maximum authority? |
| Approval policy | Which actions need a person? |
| Expiry and review | When does access end or require renewal? |
If one of these fields has no answer, the agent is not ready for high-impact access.
Read vendor scan numbers as vendor observations
The Register reported that Cyata said its scans found between one and 17 agents per employee in customer environments, with higher adoption in engineering and research roles. The article also reports that discovery scans can surface large numbers of human, machine and agent identities together.
That is evidence about one vendor's scans. It does not establish 17 agents per employee as a normal ratio, and it does not tell another organization how many agents it has. The only useful response is to build a local inventory.
Discovery should cover:
- registered OAuth clients and consent grants;
- cloud workload identities and service principals;
- API keys in secret managers, CI systems and developer configuration;
- MCP servers and their connected tools;
- browser extensions and desktop assistants with corporate access;
- agents embedded in SaaS products;
- dormant credentials tied to retired experiments.
The result needs an owner and disposition for each record: approved, restricted, remove or investigate.
Give each agent its own identity
Do not let several agents share one broad service account. A distinct identity makes four controls possible:
- Attribute actions to one runtime.
- Apply scopes for one purpose.
- Review behavior without mixing unrelated workloads.
- Revoke one agent without breaking the rest.
Prefer key-bound or workload credentials when the platform supports them. Curity recommends asymmetric mechanisms such as JWT-based workload credentials and X.509 certificates over shared secrets and API keys. Where OAuth delegation is needed, register the agent as a client and constrain the scopes it may request.
Short-lived credentials help, but short lifetime is not a complete policy. A refresh token with broad authority can preserve the same risk. Review the full chain: initial grant, refresh, token exchange, downstream API scope and revocation.
Scope tools before tuning prompts
A system prompt is not an authorization boundary. Tool configuration and API policy are.
For each tool, split authority by operation:
- read a record;
- create a draft;
- send or publish;
- modify an existing record;
- delete;
- change permissions;
- execute code;
- access secrets;
- initiate a financial transaction.
An email agent may need to search a mailbox and create drafts. That does not prove it needs permission to send externally. A coding agent may need a branch and test runner. That does not prove it needs access to protected branches or deployment credentials.
The OWASP Top 10 for Agentic Applications provides a broader risk framework for systems that plan and act across workflows. The identity response is still concrete: reduce the set of tools, narrow each tool's authority and treat content read by the agent as untrusted input.
Put approval at the consequence boundary
Requiring approval for every tool call makes the agent unusable. Requiring none turns a model decision into production authority.
Place approval where a task changes an important external state. Examples include:
- sending a message outside the organization;
- merging or deploying code;
- granting access;
- deleting or overwriting data;
- disclosing regulated or confidential information;
- moving money or accepting a legal commitment.
The approval screen should show the proposed action, target, relevant data, agent identity and initiating user or workflow. A generic "allow" button without that context is weak evidence of informed approval.
Log the action chain
A useful log answers who, why, what and result:
- agent identity and version;
- initiating user, service or schedule;
- task or request identifier;
- credential and scopes used;
- tool called and target resource;
- approval request and approver;
- policy decision;
- outcome, error and rollback state.
Do not write raw secrets or full sensitive prompts into central logs. Record stable identifiers, policy-relevant fields and redacted evidence. Curity also recommends tracing agent actions to both the agent identity and the originating user or system context.
Behavior monitoring then has a defined subject. Alerts can look for a read-only agent attempting writes, a new tool path, unusual target volume, access outside its environment or repeated denied actions. "The agent behaved strangely" is not an investigation query.
Lifecycle is the control most likely to be skipped
Every agent begins as somebody's decision. Access should end when the owner leaves, the project closes, the environment changes or the review expires.
Test deprovisioning before production:
- Disable the agent identity.
- Revoke OAuth grants, refresh tokens and downstream credentials.
- Remove tool and MCP server access.
- Confirm scheduled jobs stop.
- Preserve the audit trail.
- Verify that no shared credential keeps the agent working.
This is why ownership cannot be a free-text note. It needs to connect to an identity lifecycle process.
What I would check this week
Export the OAuth clients, workload identities and MCP connections in one environment. Select the agents that can write, send, deploy, delete or access secrets. For each one, confirm a named owner, distinct identity, exact scopes, approval boundary, logs, review date and revocation test.
Treat each agent as an application with authority. That authority needs firm bounds and an accountable owner.
Sources
- The Register: Unaccounted-for AI agents are being handed wide access
- Curity: Identity and Access Management for AI Agents
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026