Three signals landed close together. Research on automatically generating safety constraints for agent harnesses. A NIST framework published on February 17 that targets agent behavior rather than model weights, though its actual scope and legal force remain unverified. And a batch of security fixes in open-source agent tooling covering Docker token leakage and SSRF policy.
These events point to a shift: agent safety is moving from best practice toward a compliance surface, on a trajectory similar to data privacy and financial controls.
The standard conclusion from that observation is "start writing audit logs now, because retrofitting is painful." That misidentifies which part is expensive.
A log is a positive record; compliance wants a negative proof
"What did the agent do, when, and why" is a data engineering problem. It is tractable, vendors sell it, and a competent team can often bolt a reasonable version onto an existing system in a few weeks.
"Prove the agent stayed within its bounds" is a different kind of claim. It is a statement about actions that did not happen, across the space of actions the agent could have taken. No volume of logs produces it. Ten thousand clean tool calls do not reliably distinguish an agent that had hard limits from an agent that had none and got lucky.
The privacy analogy is useful here, with the caveat that I am reasoning from accounts I find credible rather than from measured data. The consent banner was the surface UI. The deep infrastructure work was data lineage: being able to say where a record came from, what basis it was held under, and everywhere it had been copied. Many teams that had never modeled lineage found it hard to generate after the fact.
Agent systems have the same structure. Action logs capture surface events. Constraint provenance requires structural state capture. To prove a negative, the system must bind a specific version of a policy to the exact execution environment of the agent and leave an immutable record of the boundary that was enforced at runtime.
Bounds have to exist outside the prompt
If bounds have to be provable, they have to exist as artifacts outside the model's context window.
An instruction in a system prompt is a request. A policy enforced at the tool boundary is a fact someone can read without trusting the model. If your only expression of "the agent may not touch production credentials" is a sentence in a prompt, your compliance story reduces to "trust us."
Look at the recent security fixes in agent tooling. Docker token leak prevention and SSRF policy are standard sandboxing work, not alignment work. They answer two questions: which credentials are reachable from inside the box, and which network destinations are allowed out of it. Those questions produce artifacts you can hand to a reviewer. Prompt engineering does not.
A versioned policy artifact in a repository is half the requirement. The harness must also guarantee, cryptographically or structurally, that the agent cannot execute without that specific policy active, and the execution log must record the hash or version of the enforced policy. That mechanical link turns a policy document into a negative proof.
On automatic constraint generation
Work on deriving constraint sets rather than handwriting them is useful, because handwritten policy is where coverage gaps frequently concentrate. I have not evaluated the coverage claims in that research and would not repeat them as settled.
The trap is subtler than "generated constraints might be wrong." A generated constraint set inherits the blind spots of whatever generated it, and generation moves accountability. A specification is something a named person signed. If nobody owns the generated constraint set, you have automated the production of an unowned document, which is worse than a short handwritten one that someone defends in a review.
The audit trail is a capability you can use
Teams that build the trail because a regulator might ask build it write-only. Data goes in and nothing meaningful comes out.
Teams that build the trail for themselves get replay for non-deterministic failures, regression corpora drawn from real traffic instead of invented fixtures, and answers to "why did it do that" in minutes rather than days. The compliance artifact falls out as a byproduct.
My intuition is that the two versions cost about the same. The difference is one design decision: whether the trail is queryable by the people who build the agent, or only by the people who audit it. Pick the second and you pay the bill without getting the tool.
What to build now, ordered by retrofit cost
- Decision records. Capture the input, the tools that were available, the version of the constraint set in force, the action taken, and the alternatives rejected. The field teams most often lack later is which policy was live at that moment.
- Versioned policy artifacts. Policy as code, in a repository, with review history and named approvers. This is what makes the negative claim arguable.
- Enforcement at the boundary. Credential scope, network egress, filesystem reach, spend ceilings. Enforced by the harness, not requested of the model, with execution tied provably to the versioned policy artifact.
- Distinct identity per agent instance, so actions attribute to something narrower than a shared service account. This maps onto existing oversight expectations. It is usually the cheapest item here to add early and demands extensive architectural rework to add late.
- A written incident path. How you halt a running agent, what you can revoke inside a few minutes, and who gets called.
Adding a log line later is trivial. Reconstructing which policy governed an action six months ago, when policy lived in mutable prompt text, is close to impractical, and usually means partial reconstruction from scattered deployment records or git history. You cannot recover information you never recorded, and mutable prompts destroy exactly that information.
What I am not claiming
I am not claiming a specific rule will bind on a specific date. A twelve to eighteen month timeline for regulatory onset is a directional inference from early framework publications plus analogy to adjacent domains, and analogies of that kind are suggestive rather than predictive.
There is also a hypothesis where statute is never the forcing function. Enterprise procurement might get there first, through security questionnaires that ask for constraint evidence and incident procedures as a condition of purchase. That path could be faster than regulation and it is less forgiving, because there is no comment period and no phase-in. You either have the artifacts when the questionnaire arrives or you lose the deal.