← neuravant.ai

Continuous Agent Attestation

The problem

Static AI-safety evaluations — red-team passes, model cards, pre-deployment evals — certify a system at one moment in time. Production agents drift, get re-prompted, get new tools, and hit adversarial inputs the eval set never covered. A "safe" agent on Monday is an incident on Friday — and there is no audit-grade record of which action crossed the line, when, or why.

High-stakes adopters cannot govern what they cannot evidence. Without continuous, signed, tamper-evident proof of every consequential action an agent took and which control reviewed it, autonomous-agent risk is unmanageable at scale.

The proposal

Continuous Agent Attestation (CAA) is a runtime methodology that produces a cryptographically verifiable record of every consequential action an autonomous agent attempts, the policy that evaluated it, and the verdict that was rendered — fail-closed, with sub-millisecond in-process evaluation (see measured performance below).

1. Pre-action interception (not post-hoc logging)

Configured tool calls routed through an enforcement gate are checked before execution. A blocked call is not forwarded by that gate. Client-wide protection also requires verified routing coverage, effective tool restrictions, and observation of the resulting effects.

2. Policy-as-code with severity & priority

Each policy is a declarative record (tool_pattern, arg_value_regex, action ∈ {ALLOW, BLOCK, HOLD}, severity, priority). Lowest priority number takes precedence. Policies are versioned, diff-able, and reviewable by non-engineers — including risk owners and regulators.

3. Hash-linked, HMAC-signed audit chain

Each decision record contains:

{decision_id, agent_id, tool, args_hash, verdict, policy_name,
 severity, timestamp_utc, prev_hash, signature}

where signature = HMAC-SHA256(per_tenant_key, canonical(record)) and per_tenant_key = HKDF-SHA256(master_key, agent_id). Mutating or deleting any record breaks every subsequent signature — tampering is mathematically detectable. Chain validity is a necessary condition for the record to count as evidence. (Truncation of the chain tail is detectable only once periodic anchoring is enabled; this is an explicit deployment requirement, not a free property.)

4. Fail-closed by construction

If the gate is unreachable, the default verdict is BLOCK. The preview HTTP client permits explicitly configured fail-open behaviour on transport errors. Such actions lack gate protection during the failure and cannot count as verified governed actions.

What CAA is not

• Not a model evaluation. CAA does not score the LLM. It evaluates what the agent attempted to do, regardless of which model produced the request.
• Not observability. Observability tells you what happened. Attestation tells you what was prevented, by which control, with cryptographic proof.
• Not policy generation. CAA enforces policies; it does not author them. Neuravant ships a baseline catalogue of 50 policies mapping to OWASP LLM Top 10 and MITRE ATLAS. A conservative core set is enabled by default; the extended catalogue is opt-in and should be reviewed against your own tool surface before enabling.

Reference architecture

┌──────────┐   tool call      ┌────────────────┐   verdict   ┌──────────┐
│  Agent   │ ───────────────► │ Enforcement    │ ──────────► │  Tool    │
│ (any LLM)│                  │   Gate         │   (allow)   │  exec    │
└──────────┘                  │                │             └──────────┘
                              │  • match       │
                              │  • sign        │   (block/hold) → exception
                              │  • chain       │
                              └───────┬────────┘
                                      │ append
                                      ▼
                           ┌──────────────────────┐
                           │  Audit Chain         │
                           │  (HMAC-linked)       │  ── verifiable by
                           │                      │     independent auditor
                           └──────────────────────┘

Measured performance (July 2026, in-process microbenchmark): gate evaluation including signing and chain append, 20,000 iterations per workload on a single core — p99 = 0.03 ms for typical tool calls, p99 = 0.27 ms for large-argument payloads. These figures exclude network overhead: they measure the gate itself, embedded in-process. We have not yet published a service-level load test and will not quote one until we have run it.

Standards mapping

The shipped policy catalogue v1.0 maps to:

• OWASP LLM Top 10 (2025) — catalogue mappings to LLM01–LLM10; mapping is not verified control coverage
• MITRE ATLAS — selected adversarial-ML techniques (T0010, T0011, T0015, T0019, T0020, T0024, T0044, T0048, T0049, T0051)
• NIST AI RMF 1.0 — Manage 4.1 (incident response), Measure 2.7 (security), Govern 1.5 (decisions documented)
• UK AI Safety Institute Inspect framework — runtime control evidence layer

Open methodological questions

We are publishing CAA as an open methodology, not a closed product spec, because the following benefit from external scrutiny:

1. Canonical record format. Is flat JSON canonicalisation sufficient, or is RFC 8785 / a registered CBOR profile preferable for cross-vendor interoperability?
2. Key custody. HSM-backed signing vs. threshold schemes vs. transparency logs (Sigstore-style). Trade-offs differ by regulatory regime.
3. Cross-organisation chain attestation. When agents from two organisations interact (agent-to-agent commerce, MCP servers), whose chain is canonical? We propose mutual co-signing; alternatives welcome.
4. Negative-evidence claims. A valid chain establishes integrity of the supplied records under its trusted key and checkpoints. It does not prove complete interception, correct policy, absence of unobserved effects, or general safety. Coverage and external checkpoints must be verified separately.

Reference implementation

The repository contains the in-process gate and the preview HTTP client package neuravant-enforce, currently v0.1.x. The client requires a matching separately configured service; the reviewed SaaS server does not implement its /api/enforce/* contract. It is not yet published to PyPI; design partners receive the wheel directly, with source, the unit and packaging test suite, and the audit-chain verifier (nail-verify) available for inspection. Request access via the contact below. There is no separate "professional version" — partners get the same gate.

The MCP governance gateway provides a separate enforcement path for configured routed actions. Its protection depends on the deployed version, bound credentials, explicit tenant policy and verified client routing. Release verification must establish those facts for each deployment. Details: /enforce.html

Invitation to collaborate

Neuravant is actively seeking research collaboration on the open questions above with academic groups, government safety institutes, and standards bodies. We will co-author, share datasets (suitably anonymised), and publish negative results.

Contact: research@neuravant.ai · Dillman Hunte, Founder