Your Agent's Decision Context Disappears After Every Call. Regulators Won't Accept That.

An agent retrieves three documents from your vector store, calls two tools, reads a customer record, and makes a decision. Five seconds later, the context window is gone. The documents, the tool results, the conversation state — all ephemeral.

A regulator asks: "What information did the agent have when it approved this loan?" You check your logs. They show the decision. They don't show what the agent was looking at when it made the decision.

The Input Evidence Gap

Most agent compliance work focuses on outputs: did the agent say the right thing? Was the output verified? Is there proof the decision was made?

Outputs matter. But outputs are half the story.

The other half is inputs. What did the agent know? What documents were retrieved? What tool results came back? What prior conversation context existed? What system prompt was active?

Regulators care about inputs because inputs explain outputs. A wrong decision made with correct inputs is a model problem. A wrong decision made with poisoned inputs is a governance problem. The distinction matters for liability.

Why Context Disappears

Agent frameworks treat context as transient by design. A typical RAG agent:

1. Receives a query
2. Retrieves relevant documents from a vector store
3. Assembles a context window (system prompt + retrieved docs + conversation history + tool results)
4. Sends the assembled context to the model
5. Gets a response
6. Discards the context

Step 6 is the problem. The context window — the actual evidence of what the agent knew — is garbage collected.

Some teams log the prompt. But "logging the prompt" and "proving the prompt" are different things. A log entry saying context_tokens: 12847 tells you the size. It doesn't tell you the content. And even if you log the full context, that log is owned by your infrastructure — it's a claim, not independent proof.

Three Scenarios Where This Breaks

Scenario 1: RAG Poisoning

Your agent retrieves documents from a vector store that was updated by another system. One of those documents contains hallucinated data from a previous agent run — a hallucination that was never caught and got embedded as "ground truth."

Your agent reads the poisoned document, treats it as fact, and makes a decision based on it.

Without proof of what was retrieved, you can't trace the contamination chain. The decision log says "approved." The approval reason says "based on retrieved documentation." Which documentation? Gone.

Scenario 2: Stale Context

Your agent retrieves a customer record that was updated 30 seconds after retrieval. The agent makes a decision based on the stale record. The customer disputes the decision.

You check the database: the record shows the updated value. Your logs show the decision. But the intermediate state — what the agent actually saw — isn't captured anywhere.

Scenario 3: Tool Result Divergence

Your agent calls an external API (credit check, fraud score, inventory lookup). The API returns a result. The agent uses that result in its decision. Later, the API provider patches a bug that was returning incorrect scores during that time window.

You need to prove what score your agent received. Not what the API should have returned — what it actually returned to your agent at that timestamp. Without context capture, you're reconstructing from indirect evidence.

What EU AI Act Requires

Article 13 (Transparency) requires that high-risk AI systems be designed so that their operation is "sufficiently transparent to enable deployers to interpret the system's output and use it appropriately."

Interpreting output requires knowing the input. If you can't show what the agent was processing when it made its decision, you can't satisfy transparency requirements.

Article 12 (Record-keeping) requires that high-risk systems "automatically record events ('logs') over the lifetime of the system." Events include "the input data for which the system has generated a request for human review."

Input data logging is explicitly required. But logging and proving are different activities. A log file on your server is self-reported evidence. Cryptographic proof of input context is independently verifiable evidence.

Context Attestation

Context attestation captures the agent's decision-time state and produces cryptographic proof of what the agent knew:

{
  "decision_id": "dec_20260401_143022",
  "agent_id": "loan-approval-v4",
  "model_id": "claude-sonnet-4-6",
  "context_attestation": {
    "system_prompt_hash": "sha256:e4a1b...",
    "retrieved_documents": [
      {
        "source": "vectorstore:customer_docs",
        "doc_id": "doc_8834",
        "content_hash": "sha256:f7c2a...",
        "retrieval_score": 0.94,
        "retrieved_at": "2026-04-01T14:30:18Z"
      },
      {
        "source": "vectorstore:policy_docs",
        "doc_id": "doc_1102",
        "content_hash": "sha256:3b8ef...",
        "retrieval_score": 0.91,
        "retrieved_at": "2026-04-01T14:30:18Z"
      }
    ],
    "tool_results": [
      {
        "tool": "credit_check_api",
        "result_hash": "sha256:a9d4c...",
        "called_at": "2026-04-01T14:30:19Z",
        "latency_ms": 340
      }
    ],
    "conversation_context_hash": "sha256:71bfa...",
    "total_context_tokens": 12847,
    "context_assembled_at": "2026-04-01T14:30:19Z"
  },
  "decision_output_hash": "sha256:c4e8f...",
  "signature": "sig_...",
  "issued_by": "trust.arkforge.tech"
}

This proof says: the agent had these specific documents, these tool results, and this conversation context when it made this decision. Each component is hashed. The entire attestation is signed by an independent witness.

If a document was poisoned, you can trace it. If a tool returned bad data, you can prove it. If the system prompt drifted, you can detect it.

Practical Implementation

Step 1: Hash Context Components

Before assembling the context window, hash each component individually:

• System prompt → SHA-256
• Each retrieved document → SHA-256 of content
• Each tool result → SHA-256 of response body
• Conversation history → SHA-256 of serialized messages

This is cheap. Hashing 50KB of context takes microseconds.

Step 2: Capture Retrieval Metadata

For each retrieved document, record:
- Source (which vector store, which collection)
- Document ID
- Retrieval score (similarity/relevance)
- Timestamp of retrieval
- Content hash

For each tool call, record:
- Tool name and version
- Input parameters (hashed if sensitive)
- Output hash
- Timestamp and latency

Step 3: Attest the Assembled Context

Once the full context is assembled but before it's sent to the model, create the attestation:

• Bundle all component hashes
• Add metadata (agent ID, model ID, timestamp)
• Sign with an independent witness (not your own infrastructure)
• Store the attestation linked to the decision ID

Step 4: Link Input Attestation to Output Proof

Your output verification already captures what the agent decided. Link it to the input attestation:

Input attestation (what the agent knew)
    ↓
Decision execution (model inference)
    ↓
Output proof (what the agent decided)

This creates a complete audit chain: inputs → decision → outputs. All three independently verifiable.

Cost and Performance

Context attestation adds minimal overhead:

• Hashing: ~0.1ms for typical context (negligible vs. model inference at 500-2000ms)
• Attestation signing: ~5ms per decision
• Storage: ~2KB per attestation (hashes + metadata, not full content)

For an agent processing 10,000 decisions/day, that's 20MB of attestation data. Compare that to the cost of a single compliance failure.

Full context archival (storing the actual content, not just hashes) is optional and depends on retention requirements. The attestation proves what the content was; archival preserves the content itself.

The RAG Trust Chain

RAG systems compound the context problem. Documents in your vector store were:
1. Ingested from somewhere (website, database, API, another agent)
2. Chunked and embedded
3. Stored with metadata
4. Retrieved based on similarity scoring

Each step is a potential corruption point. Without attestation, you're trusting the entire chain implicitly.

Context attestation doesn't fix RAG poisoning — but it makes RAG poisoning detectable. When a bad decision is traced back to a poisoned document, the attestation shows exactly which document, when it was retrieved, and what its content hash was. You can then audit the ingestion pipeline for that specific document.

What Changes for Compliance Teams

Before context attestation:
- Auditor asks: "What data did the agent use for decision X?"
- Answer: "We logged the decision output. The input context was not captured."
- Auditor marks a finding.

After context attestation:
- Auditor asks: "What data did the agent use for decision X?"
- Answer: "Here's the signed attestation showing the system prompt hash, retrieved document hashes, tool result hashes, and assembled context timestamp. Each component is independently verifiable."
- Auditor verifies the attestation signature and checks the hashes against archived content.

Next Steps

For platform engineers:
- Instrument your RAG pipeline to hash retrieved documents before context assembly
- Capture tool result hashes at invocation time
- Sign context attestations before sending to the model
- Link input attestations to output proofs for complete audit chains

For compliance officers:
- Add context attestation to your Article 12 record-keeping strategy
- Request input evidence alongside output evidence during internal audits
- Use context attestations to trace decision quality issues to specific data sources

For security teams:
- Context attestations create a detection surface for RAG poisoning
- Monitor for sudden changes in retrieved document hashes (contamination indicator)
- Use attestation data to audit the ingestion pipeline when anomalies are detected

---

EU AI Act enforcement begins August 2026. Regulators will ask what your agent knew when it decided. "We didn't capture that" is an answer — but not one that passes an audit.