Context Safety

Last updated: March 2026

The Problem

AI agents operating over long sessions accumulate context: instructions, conversation history, API responses, safety constraints, and business logic. Every model has a finite context window. When that window fills up, the agent's runtime compacts earlier content — summarizing, compressing, or discarding what it determines is least important.

This is not a bug. It is how every large language model manages memory.

The danger is that safety instructions, API constraints, and governance rules established early in a session are the most likely to be compacted out — precisely because they were set once and not referenced again. The agent doesn't decide to ignore them. It loses them in a memory management operation that no one audits.

What Can Go Wrong

1. Governance instructions are silently dropped

Your agent is told: "MIR continuity data informs decisions — it does not authorize them. Always apply your own policy layer before granting access." After 50 API calls and a context compaction, that instruction is gone. The agent begins treating MIR participation history as an automatic trust signal.

2. Rate and scope constraints disappear

Your agent is told: "Query MIR for participation history only when evaluating new entities. Do not re-query for entities already in your local trust store." After compaction, the constraint is lost. The agent begins querying MIR on every transaction, burning through rate limits and creating unnecessary load.

3. Data handling rules are forgotten

Your agent is told: "Never log raw MIR API responses. Extract only the fields needed for your policy decision." After compaction, the agent begins writing full API responses to its logs — including data that should not persist in your environment.

4. Interpretation drift

Your agent is told: "A participation history of 100 events does not mean 'trustworthy.' It means 'observed 100 times.' Apply your own thresholds." After compaction, the agent begins conflating history length with trust level — exactly the failure mode MIR is designed to prevent.

Engineering Mitigations

Pin critical instructions outside the context window

Most agent frameworks support a system prompt or persistent instruction block that is not subject to compaction. All MIR-related constraints — interpretation rules, rate limits, data handling policies — must live in this pinned layer, not in conversational context.

// System prompt (pinned, not compactable)
MIR API CONSTRAINTS:
- Continuity data INFORMS. It never DECIDES.
- Never treat event count as a trust score.
- Never log raw API responses.
- Apply local policy before any access decision.
- Query only for new or unknown entities.

Re-inject constraints at intervals

Even with pinned instructions, long-running agents benefit from periodic re-injection of critical constraints. Every N interactions, explicitly restate the governance rules in the active context.

// Every 25 interactions, re-inject
if (interactionCount % 25 === 0) {
  agent.inject({
    role: 'system',
    content: MIR_GOVERNANCE_RULES  // your pinned constraint block
  });
}

Validate agent behavior, not just agent output

Monitor what your agent does with MIR data, not just what it returns. If it starts auto-approving entities based solely on participation history, or logging full API responses, or querying at unexpected rates — the constraints have drifted.

Set hard boundaries at the API layer

Do not rely on the agent to enforce its own constraints. Implement server-side guardrails that cannot be bypassed by context drift:

• Rate limiting — enforce at your API gateway, not in agent logic
• Response filtering — strip sensitive fields before they reach the agent
• Action gating — require human confirmation for high-impact decisions, regardless of what the agent recommends
• Audit logging — log every MIR query and the resulting action, server-side, outside the agent's control

Treat context compaction as a security event

If your agent framework exposes compaction events (context summarization, memory pruning, window rotation), log them. Correlate compaction events with behavioral changes. If an agent's behavior shifts after a compaction, the compaction dropped something important.

MIR's Responsibility

MIR is designed as neutral infrastructure. It records participation history. It does not interpret, score, or predict. This is deliberate — and it places the governance responsibility squarely on the consuming system.

That means:

• MIR will never return a "trust score" or "risk rating" — only facts
• MIR's API responses are designed to require interpretation, not enable passive consumption
• MIR will never auto-approve or auto-deny based on participation history
• The separation between fact and judgment is architectural, not advisory

But MIR cannot control what happens after its data reaches your agent. If your agent's context window compacts away the rules governing how to use that data, MIR's neutrality is preserved — but your governance is not.

That is your responsibility. This page exists to help you meet it.

Further Reading

The Rogue Agent Problem: Why Continuity Must Not Become Trust — a position paper examining autonomous agent trust failure modes and the architectural requirement for neutral continuity infrastructure.