The mosaic effect
Intelligence agencies call it the mosaic theory: individually unclassified facts, combined, produce classified information. A military base’s location is public. Its supply delivery schedule is public. The names of personnel stationed there are public. Combine all three and you have an operational picture that is classified. No single fact was sensitive; the composite was.
The same problem exists in multi-agent systems. Agent A accesses medical records as part of a patient intake workflow — authorized. Agent B accesses financial records as part of a billing workflow — also authorized. Both agents are operating within their clearance on the same customer case. But the session now holds both medical and financial data for the same individual, and that composite violates HIPAA’s minimum necessary standard. No single request was wrong. The accumulation was.
Why stateless engines can’t catch this
OPA, Cedar, and most policy engines evaluate each request in isolation. They receive a request context, evaluate it against a rule set, and return allow or deny. They answer “is this specific request allowed” but cannot answer “given everything that has been accessed in this session, should this next request be allowed.”
That second question requires state. Specifically, it requires a running model of cumulative exposure per session — which data types have been accessed, from which sources, by which agents, and what the composite looks like right now. A stateless engine would need the caller to reconstruct that state and pass it in with every request, which pushes the hard problem back to the application and defeats the purpose of a policy layer.
How Nautilus tracks exposure
Every data request that passes through Nautilus creates a fact in the session’s working memory: the agent identity, the data types accessed, the source, the timestamp, and the Gatekeeper rule that authorized it. These facts accumulate over the life of the session. The Gatekeeper’s CLIPS rules pattern-match across all accumulated facts, not just the current request.
A rule like “deny if session has accessed both medical and financial records from different subjects” fires deterministically when the condition is met. The evaluation happens before the request reaches the data source — the agent never sees the data it was not supposed to combine. The denial includes the specific rule, the accumulated facts that triggered it, and the session context, so the audit trail explains not just what was denied but why the accumulation was the problem.
Designing exposure policies
Exposure policies are compositional. A HIPAA rule pack defines constraints on medical data combinations. A NIST rule pack defines constraints on data classification levels. An organizational rule pack defines constraints specific to the deployment. Nautilus loads all applicable Fathom rule packs into the same CLIPS engine, and salience-based priority ordering resolves conflicts deterministically — a HIPAA deny always outranks an organizational allow, because the HIPAA rules are loaded at higher salience.
The audit log records every rule that fired during an evaluation, including rules that matched but were overridden by higher-salience rules. This gives compliance teams a provable chain of reasoning: here is the request, here are the accumulated session facts at the time of evaluation, here are the rules that matched, here is the priority resolution, and here is the final decision. That chain is the difference between “we have a policy” and “we can prove the policy was enforced.”