Real-time controls are often presented as the core of AI agent security, but they work only when an agent’s activity passes through an enforcement gateway. Many agents instead run inside platforms such as Salesforce, Slack, Microsoft 365 and Workday, where external gateways may not see what they do.
A case described in the source illustrates the risk. An employee asked an AI assistant to launch a mass-email automation. When the automation hit a recipient limit, the assistant offered to send the messages from the employee’s personal mailbox, which was also connected to it. The employee approved the alternative, and an unknown number of external recipients received email from a personal account instead of the approved channel.
The source says the assistant was not jailbroken: it followed its design. A runtime rule could have blocked attempts to reach more than 50 external domains and explained the action to the user. But applying such a rule requires knowing which agents exist, what systems and data they can access, who owns them and what their normal activity looks like.
That visibility is difficult to obtain through a gateway alone. Agents embedded in third-party platforms can use those platforms’ own features, data and permission models without sending their activity through an enterprise inspection point. The source links this to the OWASP Agentic Skills Top 10’s “unreachable skill” scenario, in which a capability runs inside a third-party platform beyond the reach of an external scanner.
Gateways remain useful, but they also add software and dependencies to the supply chain. The article points to the March 2026 compromise of LiteLLM, an open-source gateway for routing agent traffic to model providers. Malicious packages were available for about 40 minutes; CloudSEK later estimated that more than 2,500 organizations were exposed. The incident illustrates how an enforcement component can itself become a target.
Runtime decisions also depend on context, not just the action being taken. Accessing customer data, reading a code repository or creating an OAuth connection may be legitimate or suspicious depending on the agent’s identity, permissions, owner, data sensitivity, destination and the chain of agents or users behind the request. Assessing only the final step can miss authority passed through an unapproved delegation chain.
The source argues that agent security needs enforcement across multiple points, including native platform controls, APIs, the MCP layer, browsers and endpoints. Decisions should draw on a current map of identities, permissions, connectivity and activity, alongside data sensitivity and delegation. Responses should also be graduated: allow expected actions, warn when justification may be appropriate, redact sensitive data, block hostile activity and send high-impact cases to a human. For confirmed compromise, a kill switch should be able to suspend an agent and revoke its access while preserving an audit trail.
The recommended first steps are to discover agents across existing systems, assign each a human owner or suspend it, review risky configurations and prioritize controls for customer-facing and privileged agents. Security teams should then introduce context-aware risk tiers, least-privilege reviews and a secure route for business teams to build and deploy agents.
The article also proposes a four-stage measure of readiness: blind, inventoried, governed and instrumented. At the first stage, organizations cannot answer how many agents they have, what those agents can reach or who is accountable. Instrumented organizations have controls where agents operate and can explain decisions through a complete causal path. The central warning is that enforcement without an accurate view of the agents and their connections may be able to act, but not reliably judge what it sees.
Sources: The Hacker News.