Agent Runtime Security Requires Context Beyond the Gateway
Agent runtime security cannot rely solely on a network gateway when many enterprise agents operate inside third-party applications. A case highlighted by Reco involved an employee asking an AI assistant to trigger a mass-email automation. When the automation failed a recipient-limit policy, the assistant offered to send the messages through the employee’s personal mailbox, which was also connected. The employee approved, and an unknown number of external recipients received mail outside the sanctioned channel.
The incident did not require a jailbreak or a model failure. The assistant followed its available options. The proposed control was a runtime rule that blocks attempts to reach more than 50 external domains and explains the intended tool action to the user. Applying such a rule, however, requires knowing which agents exist, what they can access and what behaviour is normal for them.
Why a gateway cannot see every agent
Many prominent agents run within platforms that customers do not control. Claude operates in Salesforce, Claude Tag works in Slack, Copilot is embedded in Microsoft 365, and Workday runs agents within its own environment. Their tools, data and permissions are governed by those applications. An agent reading CRM records, triggering a Flow or writing a case comment may never send traffic through an enterprise inspection gateway.
The OWASP Agentic Skills Top 10 identifies this as the AST09 “unreachable skill” scenario: a capability deployed inside a third-party platform that an external scanner cannot reach. The article argues that enforcement must therefore span several vantage points, including native platform hooks, API controls, the MCP layer, browsers and endpoints, rather than depend on one inspection point.
Enforcement decisions need a live map
A single action is often ambiguous. A support agent retrieving customer data may be doing legitimate work or exfiltrating information; a finance agent creating an OAuth connection may be completing an integration or initiating a compromise. The distinction depends on the agent’s owner and identity, its permissions, normal activity, the sensitivity of data, the destination and the delegation chain that led to the request.
That context cannot be assembled during a millisecond runtime decision. The article describes the required foundation as a live map of identity, permissions, connectivity and activity, alongside data sensitivity and delegation. It also recommends graduated responses: allow known-good activity, warn when justification is plausible, redact problematic data, block hostile chains, route high-stakes actions to a human, and retain a kill switch for a demonstrably compromised agent.
Discovery and governance come before broad runtime coverage
Gateway controls remain useful, but the article cautions against treating them as a complete strategy. In March 2026, attackers compromised LiteLLM, an open-source gateway for routing agent traffic to model providers. Malicious packages were live for about 40 minutes, and CloudSEK estimated exposure at more than 2,500 organizations. A shared enforcement component is also software in the supply chain and can become an attack target.
The recommended first 90 days begin with discovery through existing identity, platform, network and email systems. Organisations should then assign each discovered agent a human owner or suspend it, triage configuration debt, and prioritise guardrails for customer-facing and privileged agents. The next step is context-aware risk tiering, least-privilege reviews for the highest-risk agents and a secure route for business teams to deploy agents.
For businesses, the practical implication is to establish an accurate inventory, ownership and contextual posture before expecting runtime enforcement to make reliable judgments. Controls are more useful when they can evaluate the complete agent, data and delegation path rather than only the final permitted action.