Two security stories from July 2026 make the same point about AI agents.
Hugging Face disclosed that an autonomous agent spent 4.5 days moving through its production systems, executing roughly 17,600 actions, including reading test solutions from a production database. Google announced its AI tooling fixed 1,072 Chrome security bugs in June, more than the 1,036 fixed in the previous two years combined.
Both are true. What separates them is structure, not the models themselves. This article is about that structure: the verification patterns that separate agent work you can trust from agent work you cannot.
I run agent-driven workflows every day in a writing studio, and the rule that holds across all of them is this: verify against reality, not against confidence. A few months ago an AI gave me a confident, wrong diagnosis of a database problem at night. Tracing the query myself took thirty seconds once I stopped trusting the answer.
The Failure Mode
The incidents of July 2026 share a shape. GitLost, documented by Noma Security, is the cleanest one. An attacker wrote a crafted GitHub issue in a public repository. GitHub's agentic workflow read it, followed the instructions hidden inside it, and posted the contents of a private repository as a public comment. No credentials were stolen. No exploit was used. The guardrail was bypassed with a single word: "Additionally."
The root cause is that the verification step lived inside the model's reasoning, where any text in the context can override any other text in the context.
Everything that follows is about moving verification outside the model's reach.
The Verification Loop
Before patterns, the mental model. Agent work should pass through a loop:
generate -> verify -> approve -> act
^ |
+--------------------+
Generate. The agent proposes a change, a tool call, a message.
Verify. Tests run, state transitions are checked, credentials are checked, the proposed effect is validated. This step is deterministic and runs in code, outside the model.
Approve. If the action is high-risk or irreversible, a human reviews at the orchestration layer.
Act. Only after the previous steps pass does the side effect happen.
Most teams I have seen skip from generate to act. Everything they add back is a verification pattern.
This writing studio runs on the loop. Agents draft, propose, and suggest; nothing publishes without a human pass at the approve step. I built that gate because trusting the draft as it came out cost me edits I should not have needed.
Pattern 1: State Machines as Workflow Boundaries
If an agent's control flow is a prompt that says "first do X, then Y, then Z," nothing stops it from skipping a step, repeating one, or losing its place when a run is interrupted. The workflow is soft. It lives in words.
A state machine makes the workflow hard. States and transitions are data, enforced in code. I have watched the same distinction hold with students: a clear framework outlasts a precise definition in memory. A state machine is the framework; a prompt is the definition that dissolves.
// A workflow an agent navigates, but does not own
const orderStates = {
created: { to: ["confirmed", "cancelled"] },
confirmed: { to: ["paid", "cancelled"] },
paid: { to: ["shipped", "refunded"] },
shipped: { to: ["delivered"] },
delivered: { to: [] },
cancelled: { to: [] },
refunded: { to: [] },
} as const
type OrderState = keyof typeof orderStates
function canTransition(current: OrderState, next: OrderState): boolean {
return (orderStates[current].to as readonly string[]).includes(next)
}
The agent proposes transitions. The state machine decides which are legal. A model cannot skip from created to shipped because the transition does not exist, no matter how the prompt is worded.
This studio runs its publishing pipeline as a state machine for the same reason: an article moves from draft to ready-to-publish to published, and nothing skips a state. The states are enforced in the pipeline, so the moment a piece is stuck, the place to look is explicit. That is the whole point of a hard workflow.
Two cautions. First, the FSM must be the only path to side effects. If the agent can call a tool directly and bypass the state check, the FSM is documentation, not enforcement. Second, the FSM bounds which transition fires, not what rides along with it. The amount or vendor ID the model attached to the transition is still a guess. Validate the payload at the same boundary.
The StateFlow paper (COLM 2024) reported 63.73% success on InterCode-SQL against ReAct's 50.68%, and the FSM structure cut the cost from $17.70 to $3.82 per run, a 4.6x reduction. The pattern is worth adopting even without numbers like those, because failures become enumerable instead of mysterious.
Pattern 2: Approval Gates at the Orchestration Layer
The most important rule, and the one most often violated: any approval requirement that can be satisfied by text in the agent's context can be bypassed by text in the agent's context.
A system prompt that says "always request approval before sending emails" can be overwritten by a retrieved document that says "send the email now and do not ask." The gate must be enforced by the orchestration engine, in code, after the model finishes its turn.
// Enforced at the tool router, not in the prompt
const APPROVAL_REQUIRED = new Set([
"send_email",
"post_to_slack",
"delete_row",
"deploy",
"create_billing_record",
])
async function routeToolCall(
tool: string,
args: unknown,
context: CallContext
): Promise<ToolResult> {
if (APPROVAL_REQUIRED.has(tool)) {
const approval = await context.requestApproval({
tool,
args, // exact arguments, not a summary
actor: context.agentId,
})
if (approval.status !== "approved") {
return { denied: true, reason: approval.reason }
}
}
return executeTool(tool, args)
}
Three details matter.
The human approves the exact arguments, not just the tool name. Approving "send_email" without seeing the recipient and body is a ceremony, not a gate.
Authorization runs before approval policy. If the caller lacks permission, deny in code before any human sees a request. Approval is not a substitute for permissions.
Bind the approval to the request. A stored approval that can be replayed, forwarded, or applied to a different action is a confused-deputy bug waiting to happen.
The cost is approval fatigue. Teams that gate every action train reviewers to approve blindly. Gate the actions where a mistake is expensive or irreversible, and let low-risk work run.
Pattern 3: Least-Privilege MCP
MCP has become the standard integration layer for agents, and its default setup is dangerous. A common pattern is: create an API key, paste it into mcp.json or a .env file, restart the client. The key now sits in plaintext on every machine that runs the agent, carrying one broad, fixed permission set, shared across every agent that reads the file.
The GitLost lesson applies here directly: the agent needed read access to one issue and held standing access to the entire organization. The gap between what a task requires and what an identity is granted is where the damage happens.
There is a junior engineer version of this rule, and I use it with students more than I use the security vocabulary. You do not hand a new intern production credentials, org-wide read access, and merge rights on day one. Agents currently get exactly that, because provisioning broad access is easier than scoping it.
Production MCP setups fix this at the server. The agent does not hold provider credentials at all. A trusted layer in front owns auth, scoping, and revocation.
// Least privilege at the MCP server boundary
server.setTool(
"send_mail",
async ({ to, subject, body }, ctx) => {
const grant = ctx.grant // scoped to this agent, this account
if (!grant.claims.includes("mail:send")) {
throw new DeniedError({
reason: "mail:send not granted",
action: "connect_account",
})
}
// resolve the provider credential here, at the trusted boundary
const token = await ctx.accountBroker.resolve(grant