Continuous Attestation

Continuous Attestation is the property that an AI agent's behavior — not just its memory — is measured and cryptographically attested repeatedly. The default window is one second (1 Hz), so a relying party can detect when the agent leaves its attested trust envelope at the next window. The agent runtime produces and signs the evidence; osyrastream (service AP00012) ingests, validates, archives, accumulates, and anchors that evidence as Osyra's Pillar-3 substrate.

Where Verified Memory (AP00011) answers "what did the agent remember, and can we prove it?", Continuous Attestation answers "is the agent still behaving within its attested trust envelope, and can we prove the measurement stream was never silently edited?"

Why it matters

Behavioral telemetry for AI agents already exists in observability tools. The distinguishing property of Continuous Attestation is cryptographic non-repudiation of the drift measurement itself. A Behavioral Attestation Record (BAR) is not a telemetry point a vendor can lose or quietly mutate; it is a signed, law-bound record whose signature can be checked independently and whose position in the archived, anchored stream can be checked for tampering.

This matters most at the boundary between "the agent regressed hours ago and we found out at the next evaluation" and "the agent stepped outside its envelope and we have a signed record of it at the next one-second window." osyrastream is the continuous-time refinement: it catches trust regressions at the next per-window boundary rather than at the next evaluation epoch.

How it works

The trust hexagon and drift

Each agent has an attested baseline expressed as a six-axis trust hexagon. For every time window, the agent runtime folds the content identifiers of its upstream receipts into a window hexagon, applies the drift operator — written ⊕_streamdrift — against the baseline, and produces a drift_vector. It then constructs the canonical BAR and signs it.

AP00012 does not compute the trust hexagon or drift vector, and it does not mint or sign BARs. Its EmitBAR boundary receives an already-signed BAR and strictly validates the canonical CBOR representation, tenant binding, structural-law and session-key policy, signature, and live-window freshness before admitting the record.

Three laws every record must satisfy

The drift stream is bound by three structural invariants, enforced at verification time:

| Law | Meaning | |---|---| | T-DRIFT-1 (drift budget) | The measured drift must not exceed the configured budget for the agent's risk tier. | | T-DRIFT-2 (monotonicity) | Records within a trajectory must chain in order; the trajectory cannot be silently rewound or reordered. | | T-DRIFT-3 (baseline replay) | The record must replay consistently against the attested baseline. |

A record that violates a law is reported with a specific status rather than being silently dropped — for example DRIFT_BUDGET_EXCEEDED, MONOTONICITY_VIOLATION, or BASELINE_MISMATCH. A separate CONSISTENCY_VIOLATION status distinguishes a tampered drift vector from a legitimate budget exhaustion.

Signing happens in the upstream runtime

Each BAR is signed under a per-tenant Ed25519 session key that is itself anchored to an HSM/KMS-resident root key. The agent-side SDK's SignBAR path re-derives the baseline and drift vector before signing; SignAndEmit is exactly that upstream signing step followed by EmitBAR. AP00012 resolves the tenant-bound verification key and verifies the submitted signature. The signed bytes are canonical CBOR (the same RFC 8949 deterministic profile OME uses), so the record is byte-reproducible.

Completeness via Merkle anchoring

Signing each record proves authenticity. Proving the stream was never silently edited requires a second mechanism. osyrastream appends every BAR to a per-tenant Merkle Mountain Range (MMR) — an append-only accumulator — and periodically commits the MMR root (every 60 records by default) into the Verified Memory Jellyfish Merkle Tree owned by AP00011.

This is a deliberate division of labor:

agent runtime                  AP00012 osyrastream
compute + sign BAR ──EmitBAR──▶ validate tenant/session/signature
                               write AP00012 WORM archive
                               append to per-tenant MMR
                                          │
                                          ▼ every N records
                               AnchorCommitter ──Insert(anchor_id, root)──▶
                                                  AP00011 OME JMT

The producer owns BAR computation and signing. AP00012 owns validation, the hot MMR state, and the durable WORM cold archive itself (filesystem or S3 in deployed environments; the in-memory backend is for development). AP00011 owns the durable JMT commitment. The archived BARs plus the append-only MMR and its JMT commitments make silent edits detectable.

This is a typed bare anchor, not a signed memory Claim. Current AP00012 code derives a deterministic RFC 9562 UUIDv8 anchor_id for the canonical anchor path and sends it in OME's wire-frozen claim_id field with the 32-byte MMR root as value_hash. The current OME proto and AP00011 insert implementation treat that request as an append-only typed JMT commitment: OME does not synthesize a Claim row, issuer DID, or signature. Identical authenticated replay returns the original committed root; a different value for the same anchor is rejected.

Cross-tenant isolation is structural

Isolation between tenants is not just an authorization check. There is no global MMR root method; each tenant has its own signing key, its own domain-separation tags, its own MMR partition, and a tenant-namespaced typed anchor in AP00011's workspace JMT. This is a namespace and authorization boundary; it is not a claim that AP00011 allocates a separate tree per tenant. A record for one tenant cannot be replayed or substituted into another because the tenant is bound into the verification and commitment paths.

How Continuous Attestation relates to the rest of Osyra

A downstream policy enforcer (the AP00001 edge gateway) can subscribe to a live per-tenant drift feed and react to a misbehaving agent at ingress. AP00012 also implements its own VerifyBAR and GetTrajectory forensic-read surfaces. The durable typed anchor lives in Verified Memory (AP00011).

AP00016 is the platform's Verifier-of-Record, but no formal AP00012↔AP00016 BAR replay or adjudication bridge is implemented in V1. Treat that integration as future architecture, not as a callable product path today. AP00012's job is narrow and explicit: ingest and preserve the drift stream — it does not decide business policy on drift and does not adjudicate disputes.

Scope and roadmap

The frozen osyra-drift-v1 record format and agent-side signing path, the drift operator and its three laws, AP00012 tenant-bound verification, per-tenant MMR, AP00012-owned WORM archive, and AP00011 typed-anchor path are implemented. The live drift-event feed and distinct-active-agent count are additive extensions to the frozen format. A formal AP00012↔AP00016 bridge remains outside the implemented V1 surface.

Re-baseline handling — the envelope for a legitimate upward shift in an agent's trust hexagon that re-attests the baseline rather than flagging drift — is on the roadmap (V1.5). The records described above attest drift against a fixed baseline; re-attestation of the baseline itself is future work.