AI agents need identity, tool, and safety controls to work

At a glance

What this is: This is a WorkOS guide on building AI agents, with the core finding that identity, tool access, orchestration, authentication, and safety controls must be designed as one system.

Why it matters: It matters because IAM teams now have to govern agents that can invoke tools, hold credentials, and act on behalf of users or products across multiple systems.

Context

AI agents are software systems that plan, call tools, and complete goals across external services. That makes them different from ordinary chatbots, because their value depends on whether they can safely take action, not just generate text.

The identity problem emerges as soon as an agent is allowed to use APIs, databases, web actions, or delegated user credentials. Traditional access design assumes a stable operator and a stable task boundary, while agents may chain steps, retry actions, and shift context mid-workflow.

For AI agent programmes, the operational question is how to grant enough access for useful work without creating uncontrolled standing privilege across tools and sessions. WorkOS uses the article to argue that this design choice is inseparable from agent usefulness, not a separate security add-on.

Key questions

Q: How should teams scope AI agents without over-granting access?

A: Teams should scope AI agents to the smallest resource set needed for the task and avoid reusing the human account’s full access token. The agent’s entitlement should reflect the job it will perform, not the full breadth of what the user could do manually across the tenant.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What breaks when AI agents are connected through personal accounts or shared credentials?

A: Shared or personal credentials break accountability, lifecycle control, and revocation. If an agent inherits a human account, security teams lose clean ownership and cannot reliably attest what the identity can do or when it should be disabled. That creates an unmanaged backdoor into systems that may persist after the original setup is forgotten.

Q: How do teams decide between a single agent and multiple specialist agents?

A: Use one agent until the tool set, instructions, or ownership model becomes too large to control cleanly. Split into specialist agents when different tasks need different permissions, different teams own the work, or the orchestration logic becomes difficult to test and observe.

Technical breakdown

Why AI agent identity is not the same as chatbot access

An AI agent is a software system that interprets intent, selects actions, and calls tools to complete a goal. That means its identity must be treated as a runtime actor, not as a passive requester. A chatbot can stop at text generation; an agent can touch customer records, trigger workflows, or modify state through APIs. The security challenge is that the trust boundary moves from the prompt to the execution layer, where access scope, token handling, and action approval determine whether the agent is safe to operate.

Practical implication: Treat the agent’s identity as part of the runtime design, not as a post-deployment permission tweak.

Tool orchestration creates privilege propagation risk

Agents become useful by chaining tools, but every added tool expands the trust surface. A read-only lookup, a write action, and a handoff to another agent are not equivalent controls. Once an agent can select among tools, the main governance issue is not tool count but whether each tool is narrowly scoped, clearly named, and restricted to the minimum action set. Broad tools make it harder to predict outcomes and easier for the model to reach beyond the original user intent.

Practical implication: Scope each tool to one job and separate read, write, and delegated actions so privilege does not propagate across the stack.

Authentication for agents needs explicit delegation boundaries

When an agent acts on behalf of a user, OAuth tokens, scoped API keys, or service accounts are the access layer that defines what the agent may do and for how long. The article’s guidance reflects a basic governance truth: agent access should be intentional, time-bound where possible, and aligned to whether the agent represents a product or a person. Without that distinction, the same agent can end up mixing product-level access with user-level authority, which blurs ownership and complicates revocation, logging, and incident response.

Practical implication: Define whether the agent is acting for a product or a user before issuing credentials, and align the credential type to that boundary.

Threat narrative

Attacker objective: The attacker or failure mode seeks to turn a useful agent into a high-trust execution path that can carry out actions outside the intended task boundary.

1. Entry begins when an AI agent is granted access to external tools or user-delegated credentials that let it act beyond text generation.
2. Escalation occurs when the agent can select and chain tools across systems, creating broader reach than the original prompt implied.
3. Impact follows when over-scoped access or unsafe instructions allow the agent to modify records, move data, or trigger unintended actions at scale.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is a governance layer, not an implementation detail. Once a system can plan, call tools, and complete goals, its access model becomes part of the product design rather than a back-office control. That changes how security teams should think about authentication, delegation, logging, and revocation because the actor is now operational, not hypothetical. The implication is that AI agent governance must be designed alongside the agent itself.

Tool scope is the real control plane for agent risk. The article’s emphasis on narrowly scoped tools is more than software architecture advice. Every extra tool expands the agent’s reachable state, and broad, multi-purpose functions make privilege boundaries harder to reason about. The practitioner takeaway is to treat tool design as access design, because a poorly scoped tool can silently turn a bounded agent into a general-purpose operator.

Delegated access for agents collapses the old assumption that a single credential maps cleanly to a single human workflow. OAuth, API keys, and service accounts can all be valid, but they do not solve the governance question on their own. The harder problem is proving which actor the credential represents, what actions it may take, and when it should be revoked. The implication is that agent identity needs explicit ownership and lifecycle controls, not just authentication.

Runtime safety for agents is about preventing action drift, not just blocking bad prompts. Input filtering, output validation, human approval, and emergency stop controls matter because the harm often appears after the model has already made a tool choice. That is why agent governance must account for chained actions, retries, and handoffs, not just prompt injection. The practitioner conclusion is that safety needs to be embedded at the point of execution.

Ephemeral access assumptions are under strain as agents become normalised. Access review processes assume privilege persists long enough to be observed and certified, but agent behaviour can create short-lived yet high-impact access windows. That means identity programmes need to pay more attention to issuance, scope, and session boundaries than to retrospective review alone. The conclusion is that agent access governance shifts left into runtime control.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Agent identity is becoming a design-time control, not a deployment afterthought. As agents move from experiments into production workflows, teams will need to define who or what the agent represents before they issue access. That is the point at which IAM, PAM, and application engineering start to overlap in ways many programmes have not yet formalised.

Agent tool boundaries will matter more than model choice for day-to-day risk. The model may plan, but the tool layer determines what it can change. Organisations should expect governance reviews to shift toward action scope, delegated authority, and exception handling, because that is where agent misuse becomes operationally visible.

Access review alone will not be enough for fast-moving agent workloads. If the actor can acquire and use privilege inside a short task window, retrospective certification may arrive after the risk has already played out. Teams should watch for issuance-time controls, session-level logging, and approval gates that constrain action before execution.

For practitioners

• Define the agent’s identity model Decide whether the system acts as a product-level service account, a user-delegated actor, or a specialist sub-agent before any tool access is granted.
• Split tools by action class Separate read, write, payment, and delegation functions so the model cannot use a single broad tool to jump from inquiry to state change.
• Use scoped delegated credentials Issue OAuth tokens or API keys only for the exact systems and actions the agent needs, and align revocation with the credential owner.
• Add approval gates for high-impact actions Require human confirmation before deletions, transfers, policy changes, or other irreversible actions that the agent can trigger through tools.
• Instrument every tool call Log tool selection, inputs, outputs, retries, and delegation hops so you can reconstruct how an agent reached a risky action.

Key takeaways

• AI agents combine reasoning and execution, so their identity and access model must be governed as part of the system design.
• The highest-risk failure mode is over-scoped tool access, especially when a single agent can read, write, and delegate across systems.
• Security teams should focus on delegated credentials, narrow tool scope, and approval controls for high-impact actions.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Tool Boundary: The tool boundary is the point where an agent's model output becomes an enforced action. In agentic systems, this boundary acts like a permission layer because tool names, schemas, and implementations determine what the agent can actually do, not just what it appears able to request.
• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.