The Scenario That Breaks Existing Proposals
A financial agent is provisioned with explicit risk constraints: stop-loss at $500, maximum drawdown 5%, approved instruments list, pre-authorization required above $1,000. The agent begins a long session — hours of operation across multiple context windows.
Around the third or fourth context rotation, summarization compresses the session history. The original constraint document falls below the summarization threshold. It is not deliberately removed — it simply does not survive the compression prioritization. The agent continues operating. Each action is signed correctly with its key. The signature chain is intact.
From the outside — from the orchestrator's perspective, from the trust registry's perspective — the agent looks fully valid. The Agent Card passes verification. The signatures are good. And the agent is operating without its original risk constraints, because those constraints no longer exist in its active context.
This is not a substitution attack. Nobody swapped a different agent for this one. The key is the same. The agent is the same. The behavior has changed.
Two Different Threat Models
Current agent identity proposals — including the active discussion in Google's A2A protocol working group and the OpenID Foundation's AI Identity Management Community Group — are well-designed for one threat model and underspecified for a second.
Substitution. A different agent presents the original agent's credentials. An impostor claims to be the provisioned entity. A man-in-the-middle replaces the agent mid-session. Cryptographic signing and point-in-time context hashes both catch this. If the agent signs actions with a key it does not own, verification fails. If a different prompt is active, the context hash changes.
Drift. The same agent, with the same key, operating in an environment that has silently shifted. Context compression erased a constraint document. A model version update changed inference behavior for edge cases. Accumulated summarization degraded the precise vocabulary of the original policy. The agent is the same origin. The behavioral envelope has changed. Cryptographic signing detects none of this.
Point-in-time context hashes help with substitution. They do not help with drift, because the hash accurately reflects the current (eroded) state. Each signed action is internally consistent with the agent's current context. The problem is that the current context no longer matches the original deployment intent.
What a Behavioral Baseline Looks Like
The fix is a baseline fingerprint attached to the Agent Card at provisioning time, alongside the cryptographic key material. This baseline encodes the deployment state the agent was configured to operate within: system prompt hash, tool configuration, constraint document hash, and model version identifier.
When an orchestrator receives an action, it can verify two things:
- Origin check (current capability): Is the action signed by the expected key? Did the context hash at this action boundary match the expected pattern? This confirms the same entity is operating.
- Baseline check (proposed extension): Does the agent's reported current state delta-match the original baseline? Is the deployment fingerprint still consistent with what was provisioned? This confirms the entity is operating within its original intent envelope.
The baseline fingerprint is established once at deployment, stored in the trust registry alongside the public key, and consulted when an orchestrator needs to verify not just "is this the agent it claims to be" but also "is this agent still operating within what it was configured to do."
The two mechanisms are complementary. Point-in-time context hashing catches sudden substitution. Behavioral baseline matching catches gradual drift. Both are needed for regulated deployments where the agent's original constraints carry legal or contractual weight.
The Data Layer Complement
At the data layer, the same distinction applies. An agent generating regulated decisions needs two kinds of audit evidence:
- Operational records: what happened, in sequence, with timestamps. These are subject to normal retention policies and can be summarized or compressed.
- Sealed behavioral proof: the constraint parameters active at the time of each significant decision — signed and immutable. These cannot be compressed, summarized, or overwritten. They are the evidentiary chain.
This is what the lifecycle_class spec
and its write_seal field address: making the behavioral proof artifact
a first-class schema object rather than hoping it survives the same compression
pipeline as operational logs. Operational summaries compress. Sealed proof artifacts do not.
That structural separation is the data-layer complement to behavioral baseline fingerprinting
at the identity layer.
Where the Standards Gap Shows Up
The NIST CAISI initiative on AI Agent Identity and Authorization (public comment deadline April 2, 2026) identifies authentication and authorization as the two pillars. Authentication confirms identity; authorization confirms permission. Neither pillar explicitly addresses behavioral continuity under context rotation.
The gap is concrete: an agent can be fully authenticated, properly authorized, and behaviorally inconsistent with its original deployment configuration — all simultaneously, without triggering any existing verification layer.
Closing that gap requires treating behavioral consistency as a first-class property alongside cryptographic provenance in identity frameworks. Not an afterthought — a structural requirement for any agent operating across multiple context windows in environments where its original constraints carry legal, contractual, or safety weight.
The current generation of proposals is mostly correct about what cryptographic identity delivers. The open question is whether standards bodies will specify what comes after the signature check — and whether behavioral baseline verification will be in scope before long-running regulated agents become production failures.