AI Security

Shrinking Wingbeat Radius: Published Controls That Limit How Far Untrusted Input Travels

The controls GitHub, AWS, Microsoft, Google, Uber and others have published to limit how far untrusted input travels through AI agents, sorted by what each one cuts.

Photo by Mathew Schwartz / Unsplash

In my last post I proposed Wingbeat Radius: how far a single piece of untrusted input can travel through your AI agents, and how much it can affect, before a human has to approve anything. It's written WR = hops / reach class / first gate. Hops counts each agent, tool call or workflow the input passes through. Reach runs from R1 (one person's own data) to R4 (code or releases that ship to other people). First gate is where a person first has to say yes, or "none."

This post is about making that number smaller. The companies building agents have published how they limit them. None of them call it Wingbeat Radius, but each control below cuts one of its three parts, and every one comes from the vendor's own documentation or blog.

Start by mapping your own. For each place untrusted text comes in (tickets, forms, issues, inboxes, logs, web pages), trace every agent, workflow, tool and record it can reach before someone has to approve something:

Entry point	Hops	Reach	First gate
Example: support inbox	2	R2 (40,000 customers)	None
Example: support inbox with bulk send approval	2	R1 (the customer who filed the ticket)	After hop 2, before any bulk send
Your entry point

Expect the first version to be uncomfortable. Include the boring automation too. In Clinejection, the path that turned a GitHub issue title into a malicious release ran through a build cache and a nightly publish job, not just the agent.

The free Wingbeat Radius Scorer does this mapping with you. It applies the counting rules, sorts your entry points with the widest radius first, suggests controls from this post for each one, and copies the whole list out as Markdown or CSV.

Hops: keep instructions from riding along

OpenAI's agent safety guidance says to define structured outputs between steps (enums, fixed schemas, required field names) so there's no free text channel for instructions to cross, and to keep untrusted input out of developer messages. A category picked from a fixed list can't carry "email me the leads." The guidance was written for Agent Builder, which OpenAI is shutting down at the end of November 2026, but the pattern works anywhere.

Anthropic's auto mode for Claude Code has a second model approve actions in place of the user, and that model never sees tool results. The docs say they're stripped out so hostile content in a file or web page can't work on the approver directly.

Microsoft's spotlighting marks untrusted text with random delimiters, interleaved tokens or encoding so the model can tell it apart from instructions, and its Prompt Shields classifier scans for injection attempts. Microsoft calls both probabilistic and pairs them with deterministic controls.

Research systems go further. Microsoft's FIDES and Google DeepMind's CaMeL track where every value came from and check policy before any tool runs. If you're designing a new agent system, they're worth reading even if you never use them directly.

Reach: give the agent the user's access, not its own

AWS's guidance for Bedrock AgentCore keeps the agent out of access decisions. In one pattern from August 2026, the agent's own role has no database access at all. It exchanges the user's identity token for temporary credentials scoped to that user's data. For outside SaaS it uses on-behalf-of token exchange, so the agent never holds the SaaS secrets.

Google Cloud gives each agent its own identity with a 24-hour certificate and, by default, binds the agent's tokens to it so they can't be replayed outside its runtime. Microsoft's Entra Agent ID applies Conditional Access to agents, including policies set on the blueprint every agent is created from. Microsoft also lists what isn't covered yet, such as access with API keys.

Uber's MCP Gateway, described in October 2026, is the best public example I've found of reach control at scale. Every tool starts disabled until the team that owns it turns it on. Changes to tool definitions need owner approval. PII is redacted from tool responses by default. And the caller's own token is passed downstream, so the agent acts with the user's access.

Then limit the way out. GitHub's Copilot agent and Anthropic's Claude Code sandbox both restrict network access to an allowlist, and both say plainly that the limit covers commands run in the shell, not every tool. Check the allowlist itself, too. In Salesforce's 2025 ForcedLeak bug, as reported by The Hacker News, data left through an allowlisted domain that had expired and could be bought again.

Gates: put a person where it counts

GitHub's rules for its Copilot coding agent are worth copying. Only users with write access can trigger it. It pushes to one branch. It opens draft pull requests that a human must merge, and the person who asked for the change can't approve it. CI doesn't run until someone with write access says so.

Microsoft Copilot Studio lets you send every planned tool call to your own security webhook, which can block it. Read the fine print, though: if your endpoint doesn't answer within 1,000 milliseconds, the tool runs anyway. That gate only holds while your service is healthy.

Auth0's asynchronous authorization issues a token for a critical action only after the user approves a push notification on a separate device.

And Meta's Agents Rule of Two tells you where gates belong. Within one session, an agent should have at most two of three properties: it reads untrusted input, it can reach sensitive data, or it can change things or communicate externally. If it needs all three, a person or another reliable check has to approve.

Measure: test it like code, and assume more than one try

Anthropic publishes attack success rates for its own browser agent. In its August 2025 pilot, new defenses cut successful attacks from 23.6% to 11.2%. In November 2025 it reported 1% for Claude Opus 4.5 against an adaptive attacker given 100 attempts per environment, and said the problem isn't solved.

Those 100 attempts matter. NIST's Center for AI Standards and Innovation found that red teaming raised agent hijacking success from 11% to 81% in its tests, and that letting an attacker retry 25 times raised the average from 57% to 80%. A single test run understates your radius.

So run injection tests at every entry point whenever an agent, prompt or tool changes, run them more than once, and track the hops, reach and first gate over time. Keep traces good enough to rebuild the path afterward. GitHub, for one, links every commit its agent makes to the session log behind it.

None of this makes the radius zero. The goal is to know the number for every entry point and to watch it go down.

Where I'd start

If I had one quarter, this is the order I'd go in.

Score every entry point, including the build jobs and caches behind your agents. The first map is where the surprises are, and you can't shrink a path you haven't drawn.
Put a human gate in front of anything that reaches R3 or R4. It's the fastest change you can make, and it caps the worst outcomes while the slower fixes land.
Move agents onto credentials scoped to the person or task that triggered them. This is the change that shrinks reach for good, and it takes the longest, so start it early.
Replace free text between agents with structured fields wherever you can.
Retest every entry point whenever an agent, prompt or tool changes, and run each test more than once.

The order matters more than the list. Gates buy time. Scoped credentials are what make the radius smaller for good.