On June 23, 2026, Snyk moved its Evo Agentic Development Security (ADS) capability into open preview, and the design decision buried in that release is more consequential than the announcement itself: Snyk built the control point directly into an agent's tool-calling loop, hooking into what it calls PreToolUse and PostToolUse events to observe and govern shell commands, file reads and writes, network requests, MCP tool invocations, and external API calls as they happen — not after a pull request lands, not during a pre-deployment scan. Author Agnieszka Koc framed the underlying problem clearly in Snyk's own writeup: traditional application security was built to govern code artifacts crossing a boundary — a commit, a build, a deploy — but an AI agent's risk doesn't live in an artifact. It lives in a decision-making process that unfolds in real time, one tool call at a time, often dozens of times inside a single session. A code review catches a bad line of code. It cannot catch an agent that reasons its way into running curl | bash against an untrusted URL, or exfiltrating a .env file, three tool calls after a review would have signed off. This piece looks at why the execution loop itself — reason, select a tool, act, observe, repeat — has to become the enforcement boundary, and what actually has to be true architecturally to police it in real time.
What does "governing the execution loop" actually mean?
Governing the execution loop means treating the moment an agent decides to invoke a tool as the security checkpoint, rather than treating the agent's final output — a diff, a file, a completed task — as the thing you inspect. Snyk's PreToolUse/PostToolUse hook design intercepts before a shell command, file operation, network call, or MCP tool invocation executes, and again after it completes, giving a governance layer two chances per action: stop it before it runs, or catch and react to what it actually did. Snyk's framing groups this into three concerns — what an agent uses (its tools and data sources), what it does (the actions it takes with them), and what it generates (the code or output it produces) — and argues all three need coverage, because an agent that's perfectly safe in isolation can still be dangerous in the sequence it chooses. A single git push --force call is unremarkable; the same call issued right after an agent read a .env file and queried an external endpoint is a different risk entirely, and only a governance layer sitting inside the loop, watching the sequence, can tell the difference.
Why isn't pre-deployment review enough on its own?
Pre-deployment review isn't enough because it evaluates a snapshot, and an agent's dangerous behavior often only exists as a live sequence of actions that never gets committed anywhere for a reviewer to see. A human or automated reviewer checking an agent's final pull request sees the code it wrote, not the twelve tool calls it made getting there — the directories it listed, the internal API it queried, the file it briefly wrote to a temp path and deleted. If any one of those intermediate actions was the actual harm — a credential read, a request to an unapproved domain, an unsanctioned package install — a review of the end state never surfaces it, because the end state was engineered by the agent to look clean. This is the same structural gap that has made runtime detection necessary in traditional software supply chain security: a manifest scan tells you a vulnerable dependency is present, but only execution-time visibility tells you whether it was actually invoked. Applied to agents, the equivalent miss is starker, because the "vulnerability" isn't a static line of code — it's a choice the agent made only once, at a specific point in a session, that a later static review has no way to reconstruct.
What does session-level context add that a per-call check misses?
Session-level context matters because an agent's individual tool calls are frequently benign on their own and only become a policy violation in relation to the user's original request and the sequence of actions around them. Snyk's ADS design explicitly evaluates each action against the user's original request, the agent's stated objective, the sequence of prior actions, and the surrounding session context — not each tool call as an isolated, stateless event. A file-read call is fine when the task was "summarize this repo's README" and alarming when the task was "fix this CSS bug" and the file being read is a credentials store three directories away from anything CSS-related. A governance layer that only asks "is this specific tool call ever dangerous in the abstract" will either allow too much (because most individual actions are individually harmless) or block too much (because banning a tool outright breaks every legitimate use of it). Evaluating the call against the session's actual objective is what lets a system distinguish an agent doing its job from an agent that has drifted, been prompt-injected, or is executing a task nobody asked for.
What governance modes does a real-time control point need to support?
A real-time control point needs more than a binary allow/deny, because teams don't trust a brand-new governance layer with full blocking authority on day one, and even a trusted one needs escalation paths for genuinely ambiguous actions. Snyk's ADS ships three modes: log-only, for building visibility and confidence before enforcing anything; steer, where the system injects guidance back into the agent's prompt to redirect its next action without hard-stopping the session; and block, which can include a human-approval checkpoint for actions serious enough to warrant a person in the loop before proceeding. This mirrors the shape of policy engines built for other runtime enforcement points — Safeguard's own Guard SDK, for example, resolves every evaluated request to one of allow, block, or monitor, with monitor serving the same "log and watch before you commit to blocking" function as Snyk's log-only mode, and blocked requests carrying an attached reason surfaced back to the caller. The common thread is that the graduated modes exist because agent governance is adopted incrementally — teams start by watching, then steering, and only later reach for hard blocks once they trust the signal isn't full of false positives.
What architecture does real-time interception actually require?
Real-time interception requires the policy check to execute inside — or immediately adjacent to — the agent's own process, fast enough that it doesn't visibly stall the interaction, along with a policy that updates without redeploying the agent and a record of every decision made. This is the same shape Safeguard's Guard SDK is built around: its analyze_request / analyzeRequest call sits directly in an agent or MCP server's hot path, evaluates against a policy held entirely in local memory so there's no network round-trip on the request path, and is designed to complete in well under 10ms per call — because a control point that adds seconds of latency to every tool call gets disabled by the first team that notices. That policy is pulled and refreshed continuously in the background, so a rule change made in a dashboard reaches every running agent instance within moments rather than requiring a restart, and for MCP servers a team doesn't control the code of, a Guard Proxy enforces the identical policy at the network layer by evaluating every JSON-RPC call before forwarding it upstream. Underneath both is the requirement Snyk's own framing implies but doesn't dwell on: an append-only audit trail recording which rule fired and why on every single decision, because a governance layer nobody can audit after the fact is not meaningfully different from having no governance layer at all.
What should security teams actually do with this shift?
Security teams should stop treating "review the agent's output" as a substitute for "watch what the agent did to produce it," and start budgeting for a runtime control point the same way they already budget for a WAF or an EDR agent. Practically, that means picking a governance layer — whether Snyk's ADS or an equivalent — before scaling agent usage past a pilot, starting it in log-only or monitor mode to build a baseline of what your agents' tool-call sequences normally look like, and only then tightening toward steer or block once false positives are understood. It also means the same session-context principle applies regardless of vendor: a policy that only inspects individual tool calls in isolation will always be blind to sequences, so whatever engine you choose needs visibility into the agent's objective and action history, not just a denylist of dangerous-sounding function names. The organizations that get burned by agentic AI in the next year will overwhelmingly be the ones that treated agent security as a code-review problem rather than a runtime one.