Nearly every agent security pitch now ends on the same promise: the product stops the bad action in real time. The promise holds for one kind of agent, the kind whose traffic passes through a gateway the enterprise owns. Most agents never touch one.
One recent case shows what that gap looks like in practice. An employee asked an AI assistant to trigger a mass-email automation. The automation hit a recipient-limit policy and failed, so the assistant, which was also connected to the employee's personal mailbox, offered to send the batch from there instead. The employee approved without registering that the assistant was about to route around the sanctioned system. An unknown number of external recipients received email from a personal account rather than the approved channel.
No jailbreak was involved. The assistant did exactly what it was built to do, and the fix was not retraining a model. It was a single runtime rule that blocks any attempt to reach more than fifty external domains and explains to the user what the tool is about to do. Knowing where to apply a rule like that depends on seeing which agents exist, what they are connected to and what normal looks like for each. That visibility is the part most runtime pitches skip.
The runtime is the application, not the pipe
The year's largest agent launches placed agents inside platforms the buyer does not own. Claudeforce runs Claude inside Salesforce's trust boundary, Claude Tag lives inside Slack and Copilot lives inside Microsoft 365. Workday, which says AI now drives more than a quarter of its new annual contract value, runs its agents inside Workday. In each case the agent's tools are the application's features, its knowledge is the application's data and its permissions are the application's permission model.
A gateway can only inspect what passes through it. An agent that runs inside Salesforce, fires from a Flow, reads CRM records and writes case comments sends nothing past an inspection point, and the same is true of a Copilot agent assembling a document from SharePoint or a Slack-native agent reading years of channel history. The OWASP Agentic Skills Top 10 describes this gap as the "unreachable skill" scenario under AST09, No Governance: a capability deployed inside a third-party platform where no external scanner can go.
Security has made a move like this before. Firewalls once inspected packets by source, destination and port, until applications stopped mapping cleanly to ports and malicious traffic began to look identical to legitimate traffic. The inspection point moved up the stack to the application, where the signal lives. Agent runtime needs the same move, with a complication the earlier one never faced: the application layer belongs to someone else. A gateway-only strategy protects the agents an enterprise hosts itself, which are the fewest and the slowest growing.
The inspection point is also a target
In March 2026, attackers compromised LiteLLM, the open-source gateway that routes agent traffic to model providers. The malicious packages were live for about forty minutes, and CloudSEK later put the exposure at more than 2,500 organizations. LiteLLM is the kind of component a security-conscious team adds on purpose to watch AI traffic, which made the inspection point itself the attack vector.
None of this argues against gateways. It argues against treating any single component as the whole strategy. A gateway is more software in the supply chain, with its own release pipeline and dependencies, and it concentrates exactly the traffic an attacker wants. When enforcement is a shared component, its failure is a shared failure.
A millisecond verdict needs a memory
Runtime decisions are made in milliseconds, and the hard cases are the gray ones. A support agent pulling customer data may be doing its job or exfiltrating it. A coding agent reading a repository may be gathering context or performing reconnaissance. A finance agent creating an OAuth connection may be doing integration work or making the first move of a compromise. The action alone does not carry the verdict. The agent's identity and owner, its permissions, its normal behavior, the sensitivity of the data, the destination and the delegation chain behind the request do.
Chains raise the bar. Enforcement that evaluates only the last hop sees an authorized agent performing an action it has permission for, and misses that the authority arrived through a chain nobody approved. Judging the whole chain at runtime means already knowing it, and that knowledge cannot be assembled in a millisecond. Enforcement without that map is an air-traffic controller with a radio but no radar: commands can be issued, but the picture of which plane is headed where does not exist.
What real agent runtime looks like
Three properties follow. Enforcement has to sit where the agents are, across several vantage points such as native platform hooks, API-level controls, the MCP layer, the browser and the endpoint, rather than at a single gateway. Every verdict has to be computed against a live map of identity, permissions, connectivity and activity (IPCA), plus data sensitivity and delegation, which is what turns the gray cases into judgments. And the response menu has to be wider than block.
Mature enforcement is graduated. It allows the known-good, warns where justification is plausible, redacts where the data is the problem and blocks where the chain is hostile. It routes the highest-stakes actions to a human and keeps a kill switch for the provably compromised agent that suspends it, revokes its grants and preserves the trail. Every verdict is logged with its full causal path, because an incident review and a regulator want the same five things: the agent, the chain, the data, the destination and the policy.
Do not buy the end state
Irregular's Dan Lahav calls the mistake the end-state fallacy: assuming the properties of the eventual equilibrium apply to the transition actually underway. In runtime purchasing, it is the belief that inline enforcement will eventually see everything, so the unglamorous layers can be skipped. That end state is not available this year from any vendor at any price. Runtime coverage is partial and platform hooks are arriving unevenly.
What can be bought now, everywhere, is the stack runtime depends on: discovery across every vantage point, posture on every platform, identity and ownership for every agent and context for every decision. Each enforcement point that opens later then snaps into a map that already knows what normal looks like. The full argument for where enforcement belongs is in From AI Runtime to Agent Runtime.
The first ninety days, in order
A sequence that follows the stack bottom-up looks like this.
| Window | The work | How to know it is real |
|---|---|---|
| Weeks 1 to 2: get the number | Connect what is already running (the identity provider, major platforms, network tools, the email layer) and let discovery work across every vantage point at once. No gateway deployment, no endpoint rollout, no rerouted traffic. | Time to first insight is days, not quarters. The discovered population is several multiples of the list IT keeps. |
| Weeks 3 to 6: names and configurations | Every discovered agent gets a named human owner or is suspended. Configuration debt is triaged, starting with the platforms hosting the most reachable agents: guest-user exposures, intake features wired to agent triggers, sharing rules from three years ago. Guardrails go on customer-facing and privileged agents first. | A human raises a hand within a day when asked "whose is this?" |
| Weeks 7 to 12: the queue and the path | Context-aware risk tiering so review starts with the agent that can actually hurt the business, a least-privilege review cadence on the top tier and a sanctioned route for business teams to ship agents with secure defaults. | Any critical rating can be explained as a chain, and builders are offered a path instead of only a block. |
The enablement path matters because the builders are coming either way. Blocking teaches evasion, while a good path teaches compliance.
Teams can place themselves with a four-level test. Blind means the board's three questions (how many agents exist, what they can reach and who is accountable) have no current answer. Inventoried means the population is discovered, counted and refreshed continuously. Governed means every agent has an owner, posture is managed against baselines and risk is tiered with context. Instrumented means enforcement operates where agents run, with graduated verdicts and a full causal path in every alert. Most enterprises are at the first level, whatever the policy document says, and a vendor selling instrumentation to a blind organization is selling enforcement that can act but cannot judge.
Seven questions that sort vendors
Every vendor deck now says agent security. These questions separate vendors that built for the problem from vendors that renamed a product, because each is easy to answer well only if the architecture underneath exists.
| Ask | What a good answer looks like |
|---|---|
| Can you find agents that never authenticate through SSO? | Yes, across several independent vantage points, each seeing something the others cannot. |
| For an agent you rated critical, show me the chain. | A complete, reachable attack path (capability, reachability, asset) that an analyst can verify, not an aggregate score. |
| Does the same finding produce different severities on different agents? | Yes, demonstrated on a sandboxed agent and a customer-facing one. |
| When one agent invokes another, can you reconstruct the delegation chain? | Original requester, every hop and the final action. An audit trail that starts at the last agent is not one. |
| What context feeds an allow, block or redact verdict? | Identity, permissions, delegation and data sensitivity, not the prompt alone. |
| What happens to my protection if your enforcement component is compromised? | A specific answer that addresses the LiteLLM incident directly. |
| How long until I see my real agent inventory? | Days. A quarter is a different product. |
Platforms built around the map rather than the individual agent can answer these directly. One leading example is Reco, whose Reco Graph connects every human and non-human identity, application, permission and agent action into a single live view, so that reach, not configuration, is the unit of analysis. One measured program that applied this approach moved its posture score from 47% to 91% across 21 platforms in 30 days.
Learn more about Reco's agent discovery at reco.ai/platform.
The full ninety-day sequence, the four-level self-assessment and all fifteen vendor questions are in The Agent Security Checklist: Your First 90 Days.
About Reco
Reco is the leader in Agent Security. The Reco Platform secures agents and their operating environments where applications, identities, permissions, and workflows intersect. It discovers an organization's entire third-party ecosystem, prioritizes real risk over alert volume and remediates with precision across every human identity, agent, app and permission in the environment. Built on the Reco Graph, with new integrations delivered in hours through the Reco Factory and pre-built agent and app intelligence from the Reco Library. Security leaders at Fortune 500 enterprises choose Reco to bring order to agent proliferation and the chain reactions that follow. With more than 280 app integrations, more than 1,000 detection controls and more than 1 million agents detected, Reco brings agent security, posture management and threat detection together in one place. Learn more at reco.ai.
See what is running in your environment. Agent360 is a free assessment that shows which agents and apps are active, what they can reach and who owns them. It runs on a read-only API with no software to install and returns a written security summary and a prioritized remediation plan in five business days. Request a free Agent360 assessment.
