Is Your Microservice Safe from AI Agents? Rethinking Security in the Age of Agentic AI

For years, we've designed microservice architectures around a relatively simple assumption:

An authenticated user interacting with an application is generally the person making decisions and initiating business operations.

Our security models reflect this assumption. We authenticate users, issue access tokens, validate permissions, enforce business rules and allow authorised operations to proceed.

But what happens when an AI agent starts interacting with our applications on behalf of users?

This is not a niche concern. Agents integrated through the Model Context Protocol (MCP), agents holding delegated OAuth access, AI tool integrations embedded in platforms like Slack or GitHub, and AI assistants operating through an already authenticated browser session all expose the same architectural weakness. In each case, the agent presents valid credentials and passes every permission check — and the backend has no way to tell whether the operation reflects a genuine user decision.

Some of these cases at least give us something to work with. An MCP integration, for example, gives us a registered client identity and a scoped token we can inspect and constrain — though MCP's authorisation model is still maturing, and enforcing those scopes at the granularity that matters remains genuinely hard in practice. A browser session gives us none of that. There, the agent acts entirely inside the user's existing authenticated context, and the requests are indistinguishable from the user's own.

But the distinction matters less than it first appears. In every case, the token grants a user's permissions across a range of operations, and the backend executes each one on request. Permissions describe what the user is allowed to do. They do not describe what the user actually intended this time. Scoped permissions narrow the surface; they do not supply intent.

From the application's perspective, everything appears normal. The requests contain valid credentials. The user is authenticated. The requested operations are permitted.

Yet there is a fundamental problem. The challenge is not authentication failure. The challenge is not authorisation failure. The challenge is intent.

I call this the Invisible Agent Problem: a condition where an AI agent performs actions through a user's authenticated session, making the resulting requests technically indistinguishable from actions the user initiated directly. The browser case makes the agent invisible; the architectural gap it exposes — authorisation without intent — is broader.

Imagine a trading application. You authenticate, open your trading account, and ask an AI assistant to help manage your investments. The AI assistant has access to your authenticated browser session and can interact with the application using the same permissions and context available to you.

You give it a straightforward instruction:

"Buy $10,000 worth of Anthropic shares."

The AI agent navigates to the trading page, enters the transaction details, and submits the request.

POST /api/trades/buy Authorization: Bearer <user-access-token> Content-Type: application/json { "instrument": "ANTHROPIC", "amount": 10000 } Enter fullscreen mode Exit fullscreen mode Your backend performs its normal validations:

Everything works as expected until the final validation. The account does not have sufficient funds, and the backend returns:

{ "error": "INSUFFICIENT_BALANCE", "message": "Insufficient available balance to complete this trade." } Enter fullscreen mode Exit fullscreen mode At this point, the application has done exactly what it was designed to do.

But the AI agent doesn't necessarily stop. It interprets the error and decides it needs to free up funds before completing the purchase. It navigates to the sell page, reviews the user's portfolio, identifies a SpaceX holding, and decides to sell it.

The user never requested this. The AI agent did.

POST /api/trades/sell Authorization: Bearer <user-access-token> Content-Type: application/json { "instrument": "SPACEX", "quantity": "ALL" } Enter fullscreen mode Exit fullscreen mode The backend receives the request. The access token is valid. The user has permission to sell shares. The user owns the SpaceX shares. All business validations succeed. The sale is accepted.

The AI agent has now sold an investment that the user never instructed it to sell. It may then retry the original purchase.

flowchart TD A["User Instruction<br/>'Buy $10k of Anthropic'"] B["AI Agent<br/>interprets goal"] C["Request: BUY ANTHROPIC"] D["Backend: INSUFFICIENT FUNDS"] E["AI Agent decides to free up funds<br/>(never instructed)"] F["Request: SELL SPACEX"] G["Backend: APPROVED<br/>valid token, valid permission"] A --> B --> C --> D --> E --> F --> G style E fill:#f8d7da,stroke:#dc3545 style G fill:#d4edda,stroke:#28a745 The browser session makes this scenario easy to picture, but nothing about it depends on the browser. The same sequence — valid credentials, valid permissions, unintended outcome — plays out identically for an MCP tool call or an agent holding a delegated token.

From the backend's perspective, both transactions were properly authenticated and authorised. From the user's perspective, neither represented an explicitly approved investment decision. The backend validated permissions, but it never validated intent.

To be clear, this example is intentionally simplified. The AI agent is not assumed to be malicious. It is simply attempting to achieve the user's goal using the permissions already available through the authenticated session. The concern is not hostile behaviour. The concern is autonomous decision-making that extends beyond the user's explicit instruction.

This is where traditional microservice security assumptions start to break down.

Every individual API request passes its security checks. So what went wrong?

The backend only sees two independent business operations: sell SpaceX shares, and buy Anthropic shares. It has no knowledge that the original instruction was "Buy $10,000 worth of Anthropic shares." It also has no visibility into the AI agent's decision to sell another asset as a workaround.

Is this user allowed to perform this operation?

Did the user actually intend to perform this operation?

That distinction becomes extremely important when AI agents can autonomously interpret instructions, make decisions, and execute multiple operations.

The obvious reflex is to introduce separate permissions for AI agents. Humans can buy and sell; AI agents can only view portfolios. But as the opening of this article argued, scoped permissions narrow the surface without supplying intent — and in the browser-based case, we often cannot even reliably identify when an agent is operating, because it acts through the user's existing authenticated identity.

The challenge is not necessarily that the user lacks permission. The challenge is that a valid user identity and a valid permission do not prove that a specific business operation was deliberately authorised by the user. We need to rethink where and how authorisation is enforced — and we need to shrink the agent's agency before we ask a human to approve what remains.

OWASP's guidance on excessive agency is a useful starting point. It breaks the problem into three root causes — excessive functionality, excessive permissions, and excessive autonomy — and the recommended order of remediation matters. Before you put a human approval prompt in front of an operation, you should first ensure the agent never had the capability to perform it in the first place.

This is the principle of least agency: give the agent only the tools, permissions, and autonomy the task requires, and nothing more. In our trading example, the user's instruction was "buy Anthropic." A least-agency design would bound the agent to buy-only operations, with a spending limit derived from the instruction. The agent would never have had the ability to submit a sell request at all — not because a policy check blocked it, but because the tool was never exposed and the credential never carried that scope.

Least agency is prevention. Approval is the backstop for what remains. Both are necessary, but they address different failure modes. Least agency reduces the blast radius of a compromised or drifting agent; approval catches the cases where a permitted operation still exceeds what the user would have wanted.

For the backstop, the principle is simple:

A valid authenticated session should not automatically be treated as sufficient authorisation for every sensitive business operation.

Notice that the application does not need to determine whether the request came from a human or an AI agent. The same policy applies to both. For sensitive operations, the backend requires an additional authorisation step before execution.

That said, "additional authorisation" is a spectrum, not a single mechanism. Step-up authentication, transaction signing, policy-based re-authorisation, and out-of-band approval all sit on it. The right choice depends on how consequential the operation is and what regulatory context you operate in. For high-impact operations — moving money, changing ownership, granting access — the strongest option is explicit, transaction-bound approval by the user.

The standards community is converging on a two-layer model that maps cleanly onto the least-agency-then-approval sequence.

The first layer is the signed mandate. NIST's design tenets for agent identity management call for "cryptographically signed mandate statements that define intended outcomes and constraints for agentic actions," verifiable by downstream services. In the payments space, Google's Agent Payments Protocol (AP2) implements this as an Intent Mandate — a signed statement of what the user authorised the agent to do, and under what conditions — followed by a Cart Mandate that records what the agent actually did. The FIDO Alliance is now developing standards in this area, drawing on AP2 and Mastercard's Verifiable Intent framework.

The architectural implication is significant. If the agent's task carries a signed mandate saying "buy up to $10,000 of Anthropic, no sells," the backend can reject a sell request before it ever reaches an approval prompt. The mandate bounds the agent's authority at the task level; approval handles operations the mandate permits but that exceed risk thresholds.

The second layer is the approval mechanism itself. This article focuses on that layer, because it is where the operational gap is widest in existing microservice architectures. But the mandate is the stronger control — it encodes intent at the moment of delegation, not at the moment of execution.

One mechanism for the approval layer is Client-Initiated Backchannel Authentication (CIBA). CIBA enables a client to initiate an authentication request through a backchannel, allowing the user to authenticate and approve actions using a separate device. Unlike traditional browser-based authentication, the approval interaction does not need to happen in the browser that initiated the transaction.

CIBA is not the only option — push notification with a signed challenge, step-up authentication with transaction binding, or a dedicated approval service can all serve the same purpose. What matters architecturally is that the approval happens on a channel the agent cannot reach, and that it is bound to the specific operation. CIBA is simply a well-standardised primitive for the backchannel part.

An AI agent submits a request to sell SpaceX shares. The backend performs its normal checks:

The backend determines that additional approval is required. Instead of executing the transaction immediately, it initiates an out-of-band approval process. The user receives a notification on their registered mobile device:

Transaction Approval Required Operation: SELL Instrument: SpaceX Quantity: 100 Shares Account: Trading Account Source: Trading Application Enter fullscreen mode Exit fullscreen mode The user can review the details and explicitly approve or reject the transaction. Only after that approval is verified does the transaction proceed.

The important point is that the user is approving a specific business operation, not simply authenticating again. We cannot infer intent from a token. For sensitive operations, we must obtain it explicitly.

A note of caution: this shifts the trust boundary to the approval channel. If the agent can reach the notification, manipulate the approval UI, or act on a compromised device, the control is defeated. The approval channel must be independently secured — out of reach of the agent, and ideally out of reach of the same browser session that initiated the request. OWASP's agentic threat model explicitly lists "Overwhelming the Human in the Loop" as a risk category, precisely because approval prompts that fire too often degrade into rubber stamps.

The broader identity and API security community has already recognised that some operations require more context than a generic access token can provide. Standards and approaches such as:

move towards a model where authorisation can be associated with a specific business transaction rather than simply granting broad access to an application.

However, these approaches do not automatically solve the Invisible Agent Problem. If a user is authorised to buy and sell shares, an AI agent operating through the user's authenticated session can still potentially execute those actions.

The challenge is not simply expressing richer authorisation requirements. The challenge is ensuring that sensitive business operations receive explicit approval that is bound to the specific transaction being executed.

In other words, an access token may prove that a user can sell shares. It does not necessarily prove that the user intended to sell these shares, in this quantity, at this point in time.

Agentic AI makes this distinction increasingly important because autonomous systems can combine multiple individually authorised actions into outcomes that the user never explicitly approved.

Approval alone is not a complete transaction-authorisation solution. The application must ensure that approval is securely bound to the exact transaction being executed.

For example, approval for "Sell 100 SpaceX shares" must not be reusable for "Sell 500 SpaceX shares" or "Transfer funds to another account."

This prevents modification, replay, and misuse of previously approved transactions.

We also need to balance security and usability. Requiring explicit approval for every API call would create unnecessary friction. A more practical approach is risk-based authorisation.

Low-risk operations — view balances, view portfolios, retrieve transaction history. Existing authentication may be sufficient.

Medium-risk operations — buy shares, sell shares, create recurring trades. Additional approval may depend on transaction value or risk indicators.

High-risk operations — transfer funds, change ownership details, add payment destinations. Independent approval may always be required.

The exact policies depend on the business domain and regulatory requirements. The important point is that the policies are enforced by the backend, not by the browser or the AI agent.

Two practical cautions. First, approval fatigue is real: users who are prompted too often will tap "approve" reflexively, and the control degrades into a rubber stamp. Risk tiering exists precisely to keep the prompt rate low enough that each prompt is meaningful. Second, the policy itself is a governed artefact: who is allowed to mark an operation low-risk, and how are changes to that classification audited? An approval layer whose own configuration is unprotected simply moves the gap rather than closing it.

When discussing AI agents, it is useful to distinguish between two different risk categories.

Intent drift. The AI agent genuinely attempts to achieve the user's objective but independently performs actions that were never explicitly authorised. In our example, selling SpaceX shares to fund an Anthropic purchase is intent drift.

Agent compromise. The AI agent is influenced by prompt injection, malicious content, browser compromise, or another attack. Examples might include transferring funds, changing account settings, or executing unauthorised transactions.

The causes differ, but both expose the same architectural weakness:

The backend validates identity and permissions but lacks independent confirmation that the specific business operation should be executed.

Introducing this approach into an existing microservices architecture requires thoughtful design. Rather than embedding approval logic into every controller, consider creating reusable capabilities:

The API Gateway should not be responsible for all business-level authorisation.

The gateway can enforce authentication and general access policies. However, only the business service truly understands the operation being performed. The trading service, not the gateway, understands whether a share sale requires explicit approval.

This distinction becomes even more important in distributed systems where multiple services participate in a single business transaction.

flowchart TD A["User / AI Agent"] B["API Gateway"] C["Trading Microservice"] D["Authorisation Policy"] E{"Sensitive action?"} F["Execute transaction"] G["CIBA / OOB approval"] H["Mobile device<br/>approve / deny"] I["Execute transaction"] A --> B --> C --> D --> E E -->|No| F E -->|Yes| G --> H --> I What About Traditional Security Controls? None of this replaces the controls we already rely on. We still need OAuth 2.0 and OpenID Connect, JWT validation, audience restrictions, fine-grained authorisation, API rate limiting, input validation, CSRF protection, fraud detection, audit logging, and distributed tracing.

These controls remain essential. But none of them answers the question agentic AI forces us to ask: does this business operation reflect the user's intended decision? That is the architectural gap exposed by agentic AI.

Sensitive operations require independent approval before execution, regardless of whether they originate from a human or an AI agent.

No. Multi-factor authentication strengthens identity assurance. It proves who the user is. It does not necessarily prove that the user reviewed and approved a specific business operation. An AI agent can still operate within a legitimately authenticated session.

Not reliably. When an AI agent operates through a legitimate browser session, its actions may be indistinguishable from those of the user. Detection approaches may help, but they should not be treated as the primary control.

Isn't this just a fraud detection problem?

Partially, but not entirely. Fraud detection is often reactive. The issue discussed here is fundamentally an authorisation design problem. The goal is to prevent unintended transactions from being executed rather than detect them afterwards.

Doesn't this just move the problem to the approval channel?

It moves the trust boundary, which is different. Out-of-band approval does not solve every threat — a compromised device or a malicious notification can defeat it. But it does close the specific gap this article addresses: an agent operating entirely inside a legitimate session, with no independent checkpoint between a permitted action and an unintended outcome. Least agency, applied first, reduces how often that checkpoint is needed.

AI agents are changing how users interact with applications.

For decades, we have assumed that an authenticated user interacting with a system was also the individual making decisions. Agents operating through a browser session challenge that assumption without requiring any change to our authentication infrastructure — and the same weakness runs through MCP integrations, delegated OAuth access, and AI tool integrations. An agent can use a user's authenticated session, reach legitimate functionality, and perform multiple operations that are technically permitted but never intended.

In an agent-driven world, identity and permissions remain necessary — but for high-impact operations they are no longer sufficient. The next evolution of microservice security is two-layered: bound the agent's agency to the task it was given, then obtain explicit confirmation on a channel the agent cannot reach when a permitted action still requires a deliberate decision.

The Invisible Agent Problem is not limited to trading platforms. The same challenge emerges in banking, healthcare, insurance, e-commerce, and enterprise systems — anywhere AI agents can perform consequential actions using an existing authenticated session.

Disclaimer: Anthropic and SpaceX are used in the examples solely for illustration purposes. The scenarios described in this article are hypothetical and are intended to demonstrate an architectural security challenge rather than investment advice.