11.08.2026

AI Agents Need Identities, Not Shared Secrets

AI agents do not just answer questions. They call tools, retrieve sensitive data and take actions across enterprise systems. That makes identity the control plane for trusted autonomy.

AI Agents Need Identities, Not Shared Secrets

An AI agent is not simply another chatbot. It can choose a sequence of actions, call APIs, query business systems, create or modify records and continue operating after the person who started it has moved on. Once an agent can act, the security question changes. It is no longer only “Is the model safe?” It becomes: Which agent is this, who is accountable for it, what may it do right now and how can we stop it?
That is an identity problem.

The industry is moving quickly in this direction. In August 2026, Okta highlighted capabilities for automated access certification and standards-based registration of AI agents. At the same time, NIST is researching authentication and identity infrastructure for secure human-agent and multi-agent interactions, while OWASP’s Top 10 for Agentic Applications treats identity, tool use and excessive autonomy as core security concerns. The signal is clear: enterprises need to govern agents as first-class identities, not hide them behind shared service accounts.

Key takeaways

  • Every production agent needs a unique, discoverable identity with a named business and technical owner.
  • Authorization should be task-scoped and evaluated when an action is requested, not granted broadly at deployment time.
  • The identity chain must preserve the accountable human, application or business process behind the agent.
  • Credentials should be short-lived, auditable and revocable; shared static secrets undermine all four goals.
  • Good governance accelerates AI adoption because security teams can approve bounded use cases with evidence instead of relying on trust.

The old service-account pattern breaks at agent speed

Traditional automation often runs under a service account with a stable set of permissions. That model is already difficult to govern. With agents, it becomes dangerous because the same identity may be used for changing tasks, tools and data sources. The permission set expands, while the reason for each permission gets harder to reconstruct.

Imagine a support agent introduced to summarise tickets. It receives read access to the ticketing platform. A week later, it can search an internal knowledge base. Then it gains access to customer records, Slack and a workflow tool so it can draft replies and open follow-up tasks. Each connection looks reasonable in isolation. Together they create a powerful execution path across sensitive data and business processes.

If the agent uses a shared API key, the audit trail may show which technical account acted but not which agent, which user request or which policy decision caused the action. If the agent is compromised or starts behaving unexpectedly, security cannot reliably isolate it without disrupting other integrations that share the same credential.

The problem is not autonomy by itself. The problem is autonomy without a verifiable identity and a bounded mandate.

Three questions every agent action must answer

A workable architecture should answer three questions continuously.

1. Who is acting?
Each agent needs a stable identity that is separate from its model, runtime and human operator. The identity record should include purpose, owner, environment, risk tier, approved tools and lifecycle state. Discovery matters because agents created outside the central platform still exist; unregistered agents must be detected and brought into governance or blocked.

2. On whose behalf is it acting?
An agent may act for an employee, a customer, another service or a scheduled business process. That delegation context must travel with the request. Otherwise, downstream systems see only a powerful machine identity and lose the user-level constraints that should shape access. Preserving the delegation chain improves accountability and enables policy decisions based on both the agent and the principal behind it.

3. Is this action allowed now?
A broad “read CRM” permission is not enough. The decision should consider the requested resource, action, parameters, sensitivity, environment, time and risk signals. Reading five accounts for a sales brief is different from exporting the full customer database. A mature control plane can allow the first, deny the second and require human approval for an unusual intermediate case.

This is the difference between authenticating an agent and governing its behaviour.

A practical identity blueprint for AI agents

The following controls form a useful enterprise baseline.

Unique registration and ownership
Register every production agent in a central inventory. Require a business owner who accepts the outcome risk and a technical owner who maintains the implementation. Record the agent’s purpose in plain language. “Operations assistant” is not sufficient; “creates draft maintenance tickets from approved monitoring alerts” is.

Short-lived credentials
Prefer federation and token exchange over stored API keys. Credentials should be issued for a specific audience and expire quickly. The agent runtime should not contain a reusable secret that unlocks multiple systems. Rotation helps, but eliminating long-lived credentials is the stronger design.

Task-scoped authorization
Define the smallest set of tools and actions needed for each use case. Apply parameter constraints where possible: approved repositories, allowed data classifications, transaction limits, read-only modes or restricted destinations. Re-evaluate authorization at runtime rather than assuming yesterday’s deployment decision remains valid.

Human-in-the-loop for consequential actions
Human approval is valuable when it is tied to risk, not added to every step. Use it for irreversible, high-impact or anomalous actions such as deleting data, publishing externally, changing access, executing payments or modifying production. The approver should see the intended action, relevant context and expected impact—not a vague “Allow?” prompt.

Continuous access review and rapid revocation
Agents evolve. Their permissions must not become permanent simply because nobody revisited them. Review access against actual use, revoke stale connections and disable the agent automatically when its owner leaves, its project ends or its risk posture changes. Okta’s August 2026 product update reflects this direction by bringing access certification to AI-agent connections.

End-to-end auditability
Log the agent identity, delegated principal, tool, action, parameters, policy decision and outcome. Correlate those events across the agent platform, identity provider, SaaS applications and cloud environment. Logs should support both incident response and a business explanation: what happened, why it was permitted and who was accountable.

The business case: safer AI moves faster

Identity governance can look like friction when teams are experimenting. In practice, the absence of a repeatable control model creates more friction. Every new agent becomes a bespoke security review. Approvals depend on who is in the room. Teams either wait, work around the process or deploy shadow AI without oversight.

A standard identity pattern changes that. Low-risk agents can move through a fast path. Higher-risk agents inherit additional controls based on data sensitivity and action scope. Security reviews the architecture once and then evaluates exceptions, rather than rediscovering the same questions for every project.

For European organisations, this also supports broader governance obligations. The EU AI Act establishes a framework for trustworthy AI, while the NIST AI Risk Management Framework provides a voluntary structure to govern, map, measure and manage AI risk. Neither framework can be operationalised by policy documents alone. Identity records, runtime decisions and audit evidence turn governance intent into controls that engineering teams can implement.

A 90-day starting plan

Do not begin by buying another dashboard. Begin with one production use case and build a reusable control pattern around it.

  1. Days 1–30: Discover and classify. Inventory agents, owners, tools, credentials and connected data. Select one agent with meaningful business value and manageable impact. Define its purpose and prohibited actions.
  2. Days 31–60: Establish identity and authorization. Give the agent a unique identity, replace shared secrets where feasible, define task-scoped permissions and add risk-based approval gates.
  3. Days 61–90: Operate and measure. Connect logs, test revocation, run misuse scenarios and review access against actual behaviour. Measure approval time, unused privileges, policy exceptions and mean time to disable an agent
The result is more than a secured pilot. It is a foundation that allows the next ten agents to launch with less uncertainty.

Frequently asked questions

Is an AI agent just another non-human identity?
It is a type of non-human identity, but usually requires richer context. Traditional workloads execute predefined logic. Agents can select tools and adapt their steps, so authorization must consider intent, delegation, parameters and runtime risk in addition to the identity itself.

Can we use one service account for several agents?
Technically, yes. Operationally, it weakens accountability, isolation and revocation. Unique identities make it possible to understand and control each agent independently.

Does human approval solve agent security?
No. Approval is one control for consequential actions. It does not replace least privilege, secure tool design, input validation, monitoring or lifecycle management. Poorly designed approval prompts can also become rubber stamps.

Where should an enterprise start?
Start with an inventory and one bounded production use case. Make identity, ownership, delegated context, authorization and revocation explicit. Then convert the pattern into a reusable platform standard.

Discuss your AI security architecture

Sources

let's go