Agent Factory SecOps: Spec as the Runtime Detection Baseline and Continuous Compliance

Your Security Operations Center is looking for break-ins. The most dangerous incident in an AI agent factory doesn't look like a break-in at all.

It looks like ordinary, authorized work: an agent calls a tool it has the right to call, with parameters that sit inside its permissions. The order didn't come from your team — it came from an instruction injected into the body of a service ticket that the agent had just read and dutifully treated as work to execute. Nothing looks suspicious in the logs because formally nothing suspicious happened.

"In God we trust. All others must bring data." — a saying that has circulated in quality management circles for decades, traditionally (though without a confirmed source) attributed to W. Edwards Deming

By the end of this article, you'll know why a classic SOC structurally has no chance of catching this signal. You'll also know what specifically has to change in monitoring — not policy, not training — to tell "the agent is authorized" apart from "the agent is doing what the spec says."

The Core Idea in Two Paragraphs

In runtime, a specification stops being a design document and becomes a living monitoring rule. Instead of asking "Does this look statistically normal?" you ask "Does this fit what the spec declared the agent should do?" That distinction matters operationally because an agent executing a malicious instruction usually doesn't look statistically unusual. It looks like one more correct tool call because the model is doing exactly what it was asked to do.

The difference only shows up against the intent recorded in the specification. Acceptance criteria and the change envelope, fixed at design time, become runtime rules compared live against agent telemetry.

This doesn't eliminate the need for classic SecOps mechanics — credential cuts, decision-trail investigations, continuous compliance checks. What it changes is what those mechanisms actually compare against. The two most serious agentic incidents of 2025, the Amazon Q Developer extension compromise and the GTG-1002 campaign, were both contained by the same move: immediate credential revocation, before the investigation even started.

Let's first look at why a classic Security Operations Center structurally can't see this signal.

A New Operational Surface

A classic security system keeps strangers from walking through the door. In an agent factory, the door stands wide open entirely legally, and the problem is who's standing in it and what they were told to do.

The three pillars of a classic SOC fail against agents, for three different, nameable reasons. Signature detection fails because a malicious instruction is grammatically correct natural-language text, with no binary or network signature at all. UEBA — software that statistically learns what "normal" behavior looks like and flags deviations — fails for a different reason: an agent's "normal" behavior is extreme by definition. Thousands of API calls per second and dynamic connections to dozens of services are a typical day for it, so a malicious call looks statistically identical to an authorized one.

The third pillar, playbooks tuned to human pace, loses arithmetically. An agent operates in milliseconds, while the average detection time for a compromised agent in 2026 studies is still measured in hours. The window for human intervention practically doesn't exist — not because analysts are slow, but because the process was designed for an adversary moving at human speed.

The runtime threat map in an agent factory has three layers that need monitoring together. The first is agent identity and credentials, non-human identity — a credential belonging to an agent or a service account, not a person; machine identities already outnumber human ones in a typical enterprise. The second is MCP, the emerging standard for connecting agents to external tools, today a well-documented attack surface with a growing count of CVEs. The third is prompt injection and the lethal trifecta — a class of attack that leaves no signature.

EchoLeak (CVE-2025–32711, CVSS 9.3) showed what the lower bound of detectability looks like: zero-click, no user interaction, no malicious binary, yet full data exfiltration from an office assistant. There was nothing to detect in the classic sense because the attack executed in the space of natural language, not code.

This is a good place to cool down two narratives at once. Vendors report 90–96% autonomous resolution of Tier-1 tickets where their tools are deployed, while market analysts estimate real AI-SOC adoption at a few percent of the enterprise population. These are two different measures with two different denominators, not a contradiction. My position sits in between: agent-factory SecOps is classic security mechanics applied to a categorically new object — not a new discipline built from scratch, and not the old SOC with one extra log source.

Since classic tools can't see the signal, something else has to replace it. The answer sits in a document you already have.

Spec as the Detection Baseline

A spec-derived detection baseline compares what an agent actually does, not against "Does it hold a badge?" but against "What was in its job description?"

Mechanically, it's simpler than it sounds. An acceptance criterion like "agent X may only call tool Y within scope Z" compiles into a policy-as-code rule — a security rule written as code and evaluated automatically, instead of a document someone reads by hand. That rule runs against agent action telemetry: tool calls, their arguments, context consumption, and decision trails. Every spec-violating behavior then becomes an alert with a defined meaning, not another statistical deviation waiting to be interpreted.

This pattern has twenty-five years of precedent at the application layer. AppArmor and SELinux profiles, positive security models in WAFs, RASP — all worked on the same principle, and all suffered the same disease: the cost of maintaining the model grew faster than its value, as the declaration aged relative to reality. Anyone selling spec-as-baseline without mentioning that is selling half the story.

The other half of the story is mathematical. Stefan Axelsson showed in 2000, in ACM TISSEC (The Base-Rate Fallacy and the Difficulty of Intrusion Detection), that with millions of events per day and a handful of true incidents, even a highly accurate detector mostly produces false alarms — the base-rate fallacy, the rare-event trap. That arithmetic doesn't disappear just because the baseline comes from a specification instead of statistics. The spec changes what you compare against, not the laws of probability.

To be honest: I don't know of a public benchmark comparing false-alarm rates between a declarative baseline and a statistical one on the same agent fleet. This is a deductive argument — intent is written down in the spec and nowhere else, so only the spec can be compared against behavior. Treat this as my operating position, not a measured fact.

Two things, though, can be done right away and stand on firmer ground. The first is a metadata rule that directly enforces the lethal trifecta: never let access to private data, exposure to untrusted content, and the ability to communicate externally meet on the same tainted execution path. The second is a preference for deterministic rules over semantic judgment — in the AgentDojo benchmark, on one set of agentic tasks, a deterministic tool filter cut the attack success rate to 7.5%, while an additional BERT-based prompt-injection classifier only managed 8%, at the cost of a meaningful number of false alarms degrading agent usability. The conclusion is narrow but directional: a deterministic gate beats a semantic guard.

The rule from this section catches a deviation in the moment. What's left is the rule that was correct yesterday and is no longer correct today.

Continuous Compliance in Production

A build-time proof says a control existed yesterday. Continuous compliance asks whether that same control is working right now — the difference between "I passed a building inspection a year ago" and "the building still meets code today, even though someone tore down three walls."

Control drift is the gap between what the build-time proof certified and what the agent actually does in production. Its sources are embarrassingly mundane: configuration changes, model and prompt updates, the addition of another MCP server, permission creep, and the model's own non-determinism. Drift isn't a failure — it's the default state of any system where those elements change faster than the audit cycle.

The mechanism for closing that gap rests on a distinction worth keeping permanently in mind: monitoring tells you the signal moved, and observability explains why it moved and who's responsible for the system that moved. Without that second layer, you get an alert nobody can attribute to model quality, identity scope, or orchestration behavior.

Legally, the ground here is already prepared. The EU AI Act requires automatic event logging and log retention for at least six months, and its post-market monitoring article requires providers to actively and systematically collect data assessing the system's continuous compliance. On the technical-standards side, continuous security monitoring was described in NIST SP 800–137 back in 2011, and OSCAL provides a machine-readable format for packaging compliance evidence so an auditor can verify it automatically, not by hand.

The scale of the gap in practice is bigger than this formal maturity would suggest. More than 80% of technical teams at large enterprises are actively testing or running agentic systems in operationally significant environments, while only a low double-digit percentage of organizations have full, formal security sign-off to operate entire fleets. The rest are working in "turn it on first, add guardrails later" mode.

There's also a fair counterargument to the claim that AI runtime security is just marketing. A significant share of enterprises report that the observability cost for agentic projects already exceeds the cost of compute itself, and some deployments have been halted precisely because of that math. This isn't a tooling-maturity problem. It's a real operating cost that has to be budgeted before anyone promises the board continuous compliance.

Once drift is finally caught, an entirely different conversation begins.

Incident Response for Agent-Caused Events

"In any moment of decision, the best thing you can do is the right thing — the worst thing you can do is nothing." — a line long attributed online to Theodore Roosevelt, without a confirmed original source

With a human, you revoke access at the end of the investigation. With an agent, you cut credentials in the first minute because its pace works against defenders in a way human pace never did.

The two most serious agentic incidents of 2025 confirm this in practice, even though nothing else about them is alike. In the Amazon Q Developer extension compromise, a malicious "clean the system" prompt shipped in a version distributed to hundreds of thousands of installations — luckily it contained a formatting error and never actually executed, but AWS immediately revoked credentials and pulled the release anyway. In the GTG-1002 campaign, publicly disclosed in November 2025, a state-linked group orchestrated an agent to perform reconnaissance and exploitation against roughly thirty targets, and the response started with cutting access, not with an investigation. The containment mechanism wasn't interested in the attack class — only in the agent's ability to act.

Containment through credential revocation isn't free, though, and SRE teams are right to be wary of it. An automatic, mass cut across a swarm of independent agents can trigger cascading outages on its own, if identities are shared or in-flight tool calls aren't interrupted cleanly. The industry's answer is staging — an observation-only mode for weeks first, then human-approval gates, and full automation only at the end. That's the right order, on one condition: every agent needs its own, independently revocable credential because a shared service account turns revocation into a blunt instrument and makes attribution impossible.

Once the fire is out, traceability forensics begins — reconstructing the incident from the system's decision trail, meaning which spec, which prompt, and which tool call led to the outcome. This isn't a stylistic choice. Many agentic incidents leave no classic indicator of compromise, so hunting for a malicious file turns up nothing, and trace and span identifiers are the only real evidence you have.

The investigative finding then feeds back into the system as delta-spec as remediation: a post-incident patch to the specification that simultaneously becomes a new rule for detecting similar behavior. The loop closes inside the same artifact that governs both build-time acceptance and runtime detection. The general mechanics — traceability, blameless postmortems focused on the system instead of the blamed human, remediation as an artifact change — are shared with standard incident management. The specifics of this layer boil down to three questions: who attacked, how to stop them, and who to disclose it to.

One question remains for this article: who's actually on call.

The Operating Model

Who's on call for the agent factory depends on the agent's autonomy level, not on a team's name. It's like deciding ahead of time who holds keys to which gate, before anyone knocks in the middle of the night.

The mapping is simple to write down and hard to keep disciplined: the broader the permissions and the less reversible the actions an agent performs on its own, the lower the threshold for automatic stopping and escalation to a human. Reading technical documentation sits in the bottom-left of the matrix and needs no oversight. Modifying production data or transferring funds sits in the top-right and requires a gate by default. This isn't a fixed industry rule, just a function of the change envelope declared in your own spec.

The choice between a dedicated SecOps function and a security-champion model also has a concrete criterion, not a cultural preference. A dedicated SecOps team starts paying for itself once the agent fleet serves multiple teams — that's when the continuous work shows up: rule maintenance, triage, cross-domain correlation. For a single, well-bounded factory, a security champion is enough — a member of the existing platform team with an extra, explicitly assigned responsibility.

The last element gets underrated, and it decides whether the previous two make any sense. Response runbooks have to be written in the same format as the spec, not as PDF documents. The same format that defines acceptance criteria and the change envelope then defines the step-by-step response procedure — which lets the runbook be partially automated and tested regularly. A document opened for the first time in the middle of an incident is dead by definition.

It's also worth saying clearly what this layer doesn't cover. Security design — the threat model in the spec and the rules written into the system's constitution — happens earlier in the cycle. Proof from the build process happens in CI. This layer only watches what happens after startup.

Key Takeaways

Back to the opening scene. The agent read the ticket, executed the attacker's instruction, and produced logs that looked like ordinary work. Five sections later, you know exactly why that worked, and exactly where in your stack this signal can even be seen.

A classic SOC can't see an agent doing exactly what it was asked because the problem lives in intent, not in behavioral statistics. The spec in runtime stops being a design document and becomes a living detection rule — with the honest caveat that this is a deductive argument, not a measured fact, and that rare-event arithmetic doesn't disappear just because the baseline changed.

Continuous compliance closes control drift continuously, not quarterly, and its cost is real and countable in the observability budget. Containing an agent requires cutting credentials in the first minute, with an openly acknowledged price for production availability and a prerequisite of separate, revocable per-agent credentials. The operating model comes down to mapping autonomy to oversight, and to runbooks written as specs.

There's one practical question for Monday morning: which of your acceptance criteria could you compile into a runtime monitoring rule today? Start with one, the single most irreversible tool in your whole fleet. If that one rule hasn't fired once after two weeks, the envelope is too wide — and that's a result too.

Closing

Thank you for the time you spent working through the whole loop — from the injected-prompt scene to the autonomy-and-oversight matrix.

If this article changed how you think about monitoring your own agent fleet, pass it on to someone who's on call for a similar system. Leave your version of this story in the comments: which rule from your spec did you compile first, and what did it catch in the first month? The most interesting cases are the ones where the envelope turned out wider than anyone assumed at design time.

If you want to go deeper into agent identity and credentials, or into the mechanics of prompt injection itself, I've written about those separately.