A practitioner building production AI agents recently described their safety architecture: thirty-one hooks that run before code executes, checking intent, scope, tool permissions, and policy. Then: longitudinal logging to catch the rest.
Thirty-one pre-execution checks, and they still need continuous post-execution monitoring. That's not a gap in the architecture. That's the architecture being honest about where the problem actually lives.
The gate model and its limits
Pre-execution safety checks are well-understood engineering. You validate intent before the agent runs, confirm permissions, enforce scope constraints, and run policy evaluations against the proposed action. This is worth doing. These gates catch a real class of problems: over-permissioned agents, out-of-scope requests, unauthorized tool access.
The problem is the implicit assumption built into this model — that the agent you authorized at the gate is the same agent that will complete the task. For short, deterministic, bounded executions, that assumption holds. For long-running agents operating across multiple tool calls, dynamic context accumulation, and potentially hours of autonomous operation, it doesn't.
The gate checks the start state. The session evolves. Those are different things.
Three failure modes that happen after the gate
1. Adversarial context injection
An agent reads a document, visits a URL, or processes tool output that contains instructions designed to modify its behavior. The agent was clean at authorization time. The injection happens during execution — after the gate, inside the session. The auth layer has no visibility into this. The safety hooks that ran at the start don't run again when the injected content arrives.
This is prompt injection in its most practical form. The defense is behavioral monitoring during execution, not better pre-execution checks. You need to detect when the agent's outputs start diverging from its pre-injection baseline.
2. Context compaction drift
Long-running agents compress older context to stay within model limits. The summarization is lossy. The agent after compaction has a different effective context than the agent before — which produces measurably different outputs to the same probes. Same session, same credentials, different behavioral profile.
This isn't adversarial. There's no attacker. The drift is an emergent property of how transformer context windows work. But from an observability standpoint, it looks identical to behavioral drift from external manipulation: the agent starts responding differently, and the auth layer shows nothing wrong because the session is still valid.
Detection requires a pre-compaction behavioral baseline — a snapshot of outputs before the summarization event — and continuous comparison against it. The signals are vocabulary shift (domain-specific terms that drop out post-compaction) and response embedding distance from the baseline. Neither is captured by pre-execution checks.
3. Mid-session model or tool substitution
In multi-agent pipelines, the model serving the session can change without the session terminating. A different model version, a different backend, a tool that was updated between the authorization check and the actual invocation. The credentials are still valid. The session is still active. The behavioral profile has changed.
This is the case that makes pre-execution authentication feel like security theater. Credentials prove that an entity was authorized. They don't prove that the entity completing the task is behaviorally equivalent to the entity that was authorized. Model fingerprint binding at credential issuance would help, but no standard mechanism for this currently exists in production auth stacks.
What longitudinal logging actually buys you
Post-execution logging catches these failure modes after the fact. That's not nothing — audit trails, incident reconstruction, and compliance requirements all depend on it. But it's reactive. By the time the log reveals that an agent drifted at hour three of a six-hour autonomous run, the downstream effects are already in place.
The more valuable architecture is continuous behavioral monitoring during execution: sampling agent outputs against a fixed probe set, measuring consistency with a pre-session baseline, and alerting when divergence crosses a threshold. This turns the "gate + logging" model into "gate + continuous attestation."
The instrumentation overhead is real. Sampling outputs and running embedding comparisons mid-session adds latency and cost. But the alternative — discovering behavioral drift through post-hoc log analysis — means the damage window is bounded by log review cadence, not by detection speed.
What practitioners can do now
The full solution — behavioral attestation built into auth standards, model fingerprint binding, compaction event logging — is still being standardized. What's available now:
- Capture a behavioral baseline at session start. Before the agent begins work, run a small fixed probe set and record the outputs. This is the anchor you'll compare against later.
- Log compaction events explicitly. When the context summarization fires, record the timestamp and the pre-compaction probe outputs. This is the before/after boundary that drift detection needs.
- Add lightweight vocabulary monitoring to existing logging. Track whether domain-specific terms present in early session outputs persist through the session. Vocabulary decay is a fast signal that doesn't require embedding infrastructure.
- Treat the gate and the monitor as different instruments. Gates check authorization. Monitors check behavioral consistency. Neither substitutes for the other.
The thirty-one-hook practitioner isn't doing something wrong. They've built honest safety infrastructure that acknowledges the pre-execution layer can't see inside the session. The longitudinal logging is the right response to that constraint.
The next step is making that monitoring faster and more structural — detecting within-session failure before the log review cycle, rather than after.