Beyond EMA: Per-Action Authorization for AI Agents<br>Sign up<br>Dashboard<br>Book a demo

Sign up<br>Dashboard

Book a demo

Enterprise-Managed Authorization Is a Foundation, Not a Ceiling: Why Connected Agents Need Per-Action Authorization

Manveer Chawla<br>JUNE 23, 2026<br>13 MIN READ<br>THOUGHT LEADERSHIP

TL;DR

Enterprise-Managed Authorization (EMA) centralizes access provisioning and eliminates per-server consent prompts. It is the right solution for connection-time governance. It was not designed to authorize each individual tool call, and it does not.

AI workflows need per-action authorization to limit the blast radius of prompt injection, because attacks exploit the gap between “this agent is allowed to connect” and “this specific action should execute right now.”

A secure authorization layer must evaluate the intersection of organization policies, user delegation, and agent capability boundaries immediately before an action executes.

Production-grade deployments use a pre-execution interceptor and credential isolation to guarantee that large language models never access raw authentication tokens directly.

High-risk production deployments need action-level runtime enforcement, implemented in-house or through an action runtime such as Arcade.dev, without replacing existing corporate identity infrastructure, including EMA.

What Enterprise-Managed Authorization (EMA) Solves for MCP

Enterprise-Managed Authorization is now stable. The extension, adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers, solves the per-server OAuth consent tax that slowed enterprise MCP adoption.

Before EMA, every employee had to authorize every MCP server individually. Security teams had no centralized control. Work and personal accounts bled together. EMA eliminates all of this by making the organization’s IdP the authoritative decision-maker for MCP server access. Administrators define policy once. Users authenticate through single sign-on and inherit every server their role permits. No per-app OAuth, nothing to configure as a one-off.

Under the hood, as part of the SSO-based authorization flow, the client obtains an identity assertion and uses it to request an Identity Assertion JWT Authorization Grant (ID-JAG), which it exchanges for access tokens from each MCP server’s authorization server. Three properties follow: authorize once and inherit everywhere, centralized policy and audit for access decisions, and elimination of personal/enterprise account mixups.

This is valuable infrastructure. It is also, by design, a grant-time decision. EMA’s IdP evaluates policy when tokens are issued (and may re-evaluate on renewal), but its standardized authorization visibility does not extend to individual tool calls. EMA determines who may connect to what. It has nothing to say about whether a specific tool call, proposed by a potentially compromised agent five minutes after the token was issued, should actually execute.

That gap is where the real attacks live.

How Prompt Injection Exploits Authenticated AI Agents

In early 2025, security researcher Johann Rehberger demonstrated SpAIware: a single indirect prompt injection, delivered through a malicious website, planted persistent instructions in ChatGPT’s memory store. Those instructions survived logouts and browser restarts. The compromised instance then acted as a command-and-control relay, polling a public GitHub repository for attacker commands and writing exfiltrated data to Azure Blob Storage request logs. The CSA’s March 2026 Promptware report generalized this into a broader class of agent C2 attacks.

The agent’s built-in capabilities (web access, memory, code execution) were all legitimately available to its runtime. EMA-style centralized provisioning would not have changed the outcome. The injected instructions exploited capabilities already present in the agent’s environment, not separately provisioned OAuth connections. No authorization layer distinguished a user-initiated action from an injection-initiated one. Connection-time governance was powerless because the problem was never authentication. The agent was who it claimed to be.

In mid-2026, researchers demonstrated prompt-injection attacks through GitHub comments, issue bodies, and PR titles that hijacked Claude Code, Gemini CLI, and GitHub Copilot Agent. Across the three products, the attacks exploited pre-authorized tool capabilities to exfiltrate CI secrets; some variants also induced shell-command execution. A related academic study documented similar injection vectors across 15 GitHub Actions. Anthropic’s remediation was telling: they disallowed the ps tool rather than restricting broad tool access. The response was a band-aid on a connection-level wound.

These are not isolated demonstrations. F5 describes a banking scenario in which threat actors use prompt injection against an AI chatbot to initiate unauthorized financial transactions, with the bank identifying the loss only after multiple...