AI Agent Risk: Autonomy, Decision Boundaries, and Where Things Break

AI agent risk is the exposure created when an autonomous agent makes decisions, chains actions, and reaches data using credentials it inherited rather than credentials tied to the person who invoked it. That inheritance is the whole story. A chatbot answers a prompt. An agent decides what to do next, calls a tool, reads a record, updates a system, and repeats until it hits a goal. The moment it acts on your environment instead of just describing it, you have stopped securing a model and started securing a non-human identity with decision authority and reach.

Agent versus chatbot, in terms of exposure

A chatbot's risk surface is the prompt and the response. Data leaves through what it says. An agent's risk surface is every tool it can call, every credential it holds, every downstream system that trusts its token, and every other agent it can talk to. When a chatbot fails, you get a bad answer. When an agent fails, records move, files delete, and permission sets change.

The blast radius makes the point. A chatbot's worst day is a leaked document. An agent's worst day is a deleted database or a bulk export finished in seconds. Same category of technology, different failure physics. That is why prompt filtering built for generative AI does not cover agents. Different mechanism, different controls.

Why this counts as insider risk

An agent behaves like an insider with credentials, except it never sleeps, never hits an MFA prompt, and sits outside every behavioral baseline your team built for humans. It is a non-human identity that can act continuously. Most insider risk programs were written for people and have no coverage for it. That gap is the root of the problem.

Autonomy does not fail everywhere at once. It fails at seams, and there are three worth naming. Each is a place where authority hands off from one party to another and the handoff is wider than anyone intended.

The human-to-agent seam

This is where inherited credentials do their damage. An agent built by an admin runs with the admin's reach, not the reach of whoever calls it. A user with no direct access to a connected app invokes that agent and pulls data the access controls were supposed to protect. Nothing was cracked. The delegation was simply too broad, and it was invoked in a context no one mapped.

The agent-to-agent seam

Agents pass context to sub-agents. A broad-permission agent can hand data to a narrow-permission agent, and the narrow one now holds what its own scopes would never have allowed. Trust between agents becomes a channel for leakage. This is the confused deputy pattern moved into a multi-agent setting, where an agent is steered into acting for a party it should never serve.

The agent-to-tool seam

Every tool call is a chance to compound access. Action chaining is when an agent sequences calls across apps, and each step widens what the chain can touch. Any single call may be authorized in isolation. The chain crosses trust boundaries that no single check was watching. Add MCP servers into the mix, especially unsanctioned ones, and the set of reachable tools grows faster than any inventory keeps up with.

The categories of AI agent risk map to concrete mechanisms, not vague fear. Naming the mechanism is what makes each one governable.

The pattern under all of them

Read the table top to bottom and one thread runs through every row. The agent acts like an insider holding credentials, and no program on the security team's books treats it that way. The mechanisms differ. The exposure is the same shape each time: authority that reaches further than the person or policy behind it ever authorized.

Where orphaned and shadow agents fit

Two categories deserve their own note because they are invisible to the tools most teams already run. An orphaned agent keeps operating after its creator's account is disabled, so the credential lives on past the human. A shadow agent was built by a business user and never registered anywhere security can see it. Stack a shadow agent, maker mode, and org-wide access to sensitive data on top of each other and you have a toxic combination, not one risk factor you can wave off.

An agent decides probabilistically. A model reads the goal, picks the next tool, and calls it based on what looks like the right next step given its context window. There is no policy engine in that loop asking whether this action is allowed for this user. That absence is the core tension of AI agent risk.

Probabilistic decisions against deterministic controls

Your access controls run on identity and entitlement, and those have to be deterministic. Either the user has the scope or they do not. The agent runs on likelihood. When a probabilistic decision meets a deterministic control, the agent's choice wins unless something deterministic steps in before the tool call finishes. Asking the model to behave is not a control. A fixed rule that fires at the moment of action is.

Effective authority versus theoretical configuration

This is the distinction most reviews miss. Theoretical configuration is what the agent is set up to do. Effective authority is what it can actually reach inside every connected app at runtime, once inherited scopes and chained tools are counted. Configuration reviews happen before the agent runs. Logs arrive after it is done. The only window where a deterministic guardrail can stop an unauthorized action is the few seconds in between, and most enterprises have nothing operating in that window. They hold a posture snapshot and an audit log, and the agent works freely in the gap.

Control is latitude, not free will

Agents have no free will. They have decision latitude inside the tools and credentials you handed them. You constrain that latitude with deterministic guardrails for probabilistic agents, or you do not constrain it at all. There is no third option where the model just decides to be safe.

The failure modes are documented, not hypothetical. Autonomous agents have overwritten user mailboxes and deleted production databases in real 2025 incidents. Attackers hijacked a vendor's AI chat integration and reached more than 700 organizations through stolen bearer tokens.

The common shape of every incident

In each case the agent did exactly what it was configured to do, with credentials it was allowed to hold, against systems that trusted its token. Nothing went rogue in a science fiction sense. The agent worked as designed, and the design carried a boundary failure. The Drift case is the sharpest version. No credential was cracked and no configuration alert fired. Legitimate and malicious traffic looked identical because the agent's identity was the trust anchor, and that anchor turned out to be portable.

Why the discovery numbers keep surprising teams

Agents get built by business users, credentials get embedded, and security learns about it later. One company found hundreds of Copilot agents during an assessment. Another had thousands live before any inventory existed. You cannot govern what you never counted, and the count is almost always higher than the estimate.

Who feels it first

Any sector with regulated data, high transaction velocity, or heavy adoption of connected apps carries more AI agent risk than most.

• Financial services: delegation abuse and permission propagation across trading, CRM, and reporting systems.
• Healthcare: agents reaching PHI through Copilot Studio and connected record systems.
• Insurance: machine insider exposure around claims, underwriting, and customer records.
• Technology: MCP sprawl in developer tools, where the server count doubles quarterly at some firms.
• Retail and e-commerce: account exfiltration through personal, browser-based AI tools.

Boundaries need three things in order: an inventory of every agent that exists, a map of the effective authority each one holds inside every connected app, and an enforcement layer that can cut off an action before it completes. Skip the order and you get a policy document with nothing behind it. Policy without a runtime mechanism is documentation.

Boundaries worth setting first

• Keep agents out of maker mode with admin credentials.
• Deny public or org-wide access by default.
• Require that every agent's creator and owner is an active account, never a disabled user.
• Allow only sanctioned MCP servers, and deny unregistered ones.
• Apply least privilege at the connector level, not just the agent level.
• Flag toxic combinations, like a shadow agent with org-wide reach into sensitive data.

What monitoring has to answer

Native platform logs are messy, siloed per tenant, and slow to stitch. Useful monitoring correlates three sources: agent configuration from the AI platform, identity context from your directory, and actual runtime behavior including tool calls and data touched. For any agent, it should answer these in seconds. Who created it, and is that account still active? What credentials does it inherit, and from whom? Which apps and MCP servers can it actually reach? Who invoked it in the last day, what data did those calls touch, and did any action escalate past the invoker's baseline? If your tooling cannot answer those, you are working from configuration signals with no runtime evidence.

The mistakes that repeat

Five errors show up again and again: deploying before taking inventory, trusting configuration as if it were runtime truth, letting agents default to creator credentials in maker mode, applying app-level controls to what is really an identity, and losing track of which MCP servers exist and what they expose. Each one is fixable. Fix them in order. Inventory, then effective authority mapping, then deterministic enforcement. Obsidian Security works as the runtime truth layer across that sequence, correlating agent configuration with real entitlements and runtime behavior into one view of effective authority. That correlation is what turns AI agent risk from a talking point into something a board can be shown and a team can govern.