Write the blog post:
semantic complete mediation 

ChatGPT Prompt

For decades, one of the foundational ideas in computer security has been complete mediation: every access to every protected resource should be checked against an authorization policy.

It is a powerful principle. It is also increasingly incomplete.

Modern systems don’t operate only on files, database rows, API endpoints, and permissions. They operate on meaning.

An AI agent might be allowed to read a document but should not reveal the confidential information contained inside it. A data platform might permit access to two datasets independently while their combination exposes something sensitive. A model might be authorized to answer questions using internal data while still needing to distinguish between what a user can retrieve and what they are allowed to infer.

This suggests a stronger security principle:

Semantic complete mediation means mediating not just access to resources, but access to the meaning that can be derived from them.

From Objects to Meaning

Traditional complete mediation asks a relatively concrete question:

Is this principal allowed to perform this operation on this object?

For example:

• Can Alice read this file?
• Can this service query this table?
• Can this process call this API?
• Can this user download this object?

These checks remain essential. But they assume that the security boundary maps reasonably well to the resource boundary.

Increasingly, it doesn’t.

Suppose a user cannot access a table containing employee salaries. Blocking SELECT against that table is straightforward.

But what if an AI system has access to several permitted sources and can infer an employee’s approximate salary from their title, compensation band, equity grant, and organizational level?

No forbidden object was accessed.

The forbidden information was still produced.

The distinction is fundamental:

Syntactic mediation governs what data can be accessed. Semantic mediation governs what information can be learned or produced.

Why AI Changes the Security Boundary

Software has always been capable of deriving new information from existing data. AI systems make this capability dramatically more general.

An LLM connected to enterprise data can summarize, correlate, translate, classify, infer, and synthesize information across many sources. Agents add another dimension: they can decide which resources to access and which operations to perform in pursuit of a goal.

As a result, authorization can no longer be treated purely as a gate in front of retrieval.

Consider an agent answering:

“Which of our customers are likely evaluating a competitor?”

The answer might involve CRM records, support conversations, product telemetry, emails, contracts, and account notes.

Each individual access might be authorized.

But the resulting conclusion is a new semantic object.

Who is authorized to receive that conclusion?

Traditional access control does not necessarily answer that question.

The Semantic Authorization Problem

A useful way to think about modern authorization is as a pipeline:

Identity → Resources → Computation → Derived Information → Output

Most security systems mediate heavily at the beginning of this pipeline.

They authenticate the user. They check permissions. They authorize API calls. They filter rows and columns.

But once permitted information enters a sufficiently capable computation, enforcement often becomes weaker.

Semantic complete mediation extends the security boundary across the entire pipeline.

Before producing an answer, a system should be able to reason about questions such as:

1. Who is asking?
2. What information are they permitted to access?
3. What information can be derived from those resources?
4. Does combining permitted information create a restricted result?
5. Is the resulting output itself authorized for this principal and context?

The fifth question is the important addition.

Authorization doesn’t end when data is retrieved.

The Composition Problem

Semantic mediation becomes especially important when information is combined.

Imagine three facts:

• Fact A is public.
• Fact B is public.
• Fact C is confidential.

But C can be reliably inferred by combining A and B.

An access-control system operating exclusively at the object level sees no violation when a user accesses A and B. A semantic system must recognize that producing C changes the effective information available to the user.

This problem appears everywhere.

A customer list combined with public funding announcements can reveal sales strategy.

Infrastructure metadata combined with deployment history can expose operational weaknesses.

Anonymized records combined with external datasets can sometimes identify individuals.

Individual facts can be harmless while their intersection is sensitive.

This means security labels cannot always be properties of objects alone.

Sometimes they are properties of computations and conclusions.

Retrieval Authorization Is Not Enough

One tempting architecture for secure AI is:

1. Authenticate the user.
2. Restrict retrieval to resources they can access.
3. Give those resources to the model.
4. Return the model’s answer.

This is a strong starting point. It prevents the model from simply bypassing existing access controls.

But it does not provide semantic complete mediation.

The model may still transform authorized inputs into an unauthorized output.

A stronger architecture treats generation itself as a security-sensitive operation:

Retrieve → Compute → Classify meaning → Authorize output → Release

In other words, the final answer needs a security boundary too.

Provenance Becomes a Security Primitive

Semantic authorization is difficult if a system cannot explain where an answer came from.

That makes provenance unusually important.

For a generated claim, we want to know:

• Which sources contributed to it?
• Which principals and policies govern those sources?
• Which transformations produced the claim?
• Which other claims were combined?
• What sensitivity should propagate to the result?

Instead of treating an AI answer as an opaque string, we can treat it as the terminal node of a provenance graph.Source A ──┐ ├── Transformation ── Derived Claim ── Authorization ── Output Source B ──┘

Now authorization can operate over both the inputs and the derivation.

This creates the possibility of policies such as:

Information derived from confidential customer data remains confidential unless an explicitly approved transformation declassifies it.

That is much closer to information-flow security than conventional endpoint authorization.

Semantic Policies

Object-level policies tend to look like this:

Engineering can read /production/logs/*.

Semantic policies look different:

Engineering can use production logs for debugging but cannot expose customer secrets contained in those logs.

Or:

Sales can access individual account activity but cannot generate cross-customer competitive intelligence.

Or:

Support can summarize a customer’s history for that customer but cannot use one customer’s private information when answering another customer’s question.

These policies contain concepts such as purpose, inference, audience, context, and meaning.

That makes them harder to enforce.

It also makes them closer to the security policies organizations actually intend.

The Hard Part: Meaning Is Probabilistic

There is an uncomfortable difference between semantic mediation and traditional access control.

File permissions can usually be evaluated deterministically.

Meaning cannot.

Two sentences can communicate essentially the same sensitive information using completely different words. A seemingly harmless answer may imply a restricted fact. Whether information is sensitive can depend on context and on what the recipient already knows.

Semantic mediation therefore cannot simply be implemented as a larger collection of regexes.

It requires multiple layers of enforcement.

Deterministic controls should remain deterministic wherever possible: identity, capabilities, resource permissions, data classification, execution boundaries, and information-flow constraints.

Semantic models can then operate where interpretation is genuinely necessary.

The goal should not be to replace conventional security with an LLM deciding whether something “looks safe.”

It should be to extend conventional security into places where conventional object boundaries no longer capture the thing being protected.

A Reference Architecture

A system pursuing semantic complete mediation might contain several layers.

1. Identity and context

Establish the principal, organization, role, purpose, environment, and relevant policy context.

2. Resource authorization

Apply conventional access controls before information enters the computation.

3. Provenance tracking

Maintain the lineage of retrieved information and derived claims.

4. Information propagation

Propagate sensitivity and policy constraints through transformations.

5. Semantic analysis

Identify sensitive concepts, prohibited combinations, restricted inferences, or policy-relevant meaning in generated results.

6. Output authorization

Evaluate the proposed answer against the user’s authority and the provenance of the information it contains.

7. Release or transformation

Return the answer, redact restricted information, provide a less specific answer, or deny the request.

This makes authorization a property of the computation rather than a single checkpoint before it.

Complete Mediation, Revisited

The original principle of complete mediation remains exactly right:

Every access to something protected should be checked.

What has changed is our understanding of the protected thing.

In traditional systems, the protected thing was often an object.

In AI-native systems, it may be an inference.

A summary.

A prediction.

A correlation.

A conclusion.

A piece of knowledge synthesized from hundreds of individually permitted observations.

Once systems can routinely manufacture new information, controlling access to stored information is no longer sufficient.

We also need to control the transition from data a system can access to meaning a system can reveal.

That is semantic complete mediation.

And as software becomes increasingly capable of reasoning across organizational data, it may become one of the defining security problems of the AI era.

Appendix I: Managing Boundaries

Semantic complete mediation is ultimately a problem of boundary management.

A system has boundaries around what it can access, what it can combine, what it can infer, and what it can reveal. These boundaries are related, but they are not identical.

The useful distinction is between four boundaries:

Access boundary
What information may enter the computation?

Composition boundary
Which pieces of information may be combined in the same computation?

Inference boundary
What conclusions may the system derive from otherwise permitted information?

Release boundary
What information may leave the computation and reach a particular principal?

Traditional authorization concentrates on the first boundary. Semantic complete mediation requires managing all four.

The important property is that boundaries survive transformation.

If restricted information is summarized, joined, embedded, classified, aggregated, or passed through a model, the resulting artifact does not automatically become unrestricted simply because its representation changed.

Likewise, two independently unrestricted inputs do not guarantee an unrestricted output. Their composition may reveal information neither input exposes independently.

This gives us a simple model: ┌─────────────────────────────┐ │ ACCESS BOUNDARY │ │ │ Inputs ──┤ ┌─────────────────────┐ │ │ │ COMPOSITION BOUNDARY│ │ │ │ │ │ │ │ ┌─────────────┐ │ │ │ │ │ INFERENCE │ │ │ │ │ │ BOUNDARY │ │ │ │ │ └─────────────┘ │ │ │ └─────────────────────┘ │ │ │ └──────────────┬──────────────┘ │ RELEASE BOUNDARY │ ▼ User

The enforcement question therefore changes as information moves through the system.

At ingress:

May this principal introduce or retrieve this information?

During computation:

May these information flows meet?

At inference:

Does this computation create a protected fact?

At egress:

May this principal receive what the system now knows?

The last question is especially important.

A secure system cannot assume that because every input crossed an authorized boundary, every possible output is authorized too.

Boundaries must follow information, not merely infrastructure.

That means provenance, classification, identity, policy, and transformation history need to remain connected as information moves through a system. A boundary that disappears at an API call, vector embedding, model context window, or agent handoff is not actually a security boundary.

The objective is not to prevent systems from deriving new knowledge. That capability is precisely why these systems are valuable.

The objective is to make the production and movement of that knowledge governable.

In a world of increasingly capable agents, the fundamental unit of security is no longer only the resource.

It is the information flow across a boundary.

Appendix II: Organizational Implications

Semantic complete mediation is not only a technical architecture. It changes how organizations think about ownership, authorization, and responsibility.

Most organizations divide responsibility according to systems.

Security owns identity and access controls. Data teams own datasets and pipelines. Application teams own APIs. Legal and compliance define restrictions. Business teams decide how information should be used.

AI cuts across these boundaries.

An agent can retrieve information owned by one team, combine it with information owned by another, derive a conclusion neither team explicitly created, and deliver that conclusion to a user through an application owned by a third.

The organizational question becomes:

Who owns the boundary around the derived information?

Policy Must Follow Information

Organizations often encode policy at the point where data is stored.

A database has permissions. A document has an ACL. A SaaS application has roles. A bucket has policies.

These controls answer important questions about custody.

They do not necessarily answer questions about use.

When information moves into an AI system, the organization needs to preserve not only its provenance but also the policies associated with it.

A useful principle is:

Moving information should not silently remove the obligations attached to it.

Copying a document into an index should not erase its permissions.

Turning records into embeddings should not erase their classification.

Summarizing restricted information should not automatically produce an unrestricted summary.

Passing information between agents should not reset its provenance.

Organizational policy therefore needs to become portable alongside information.

Ownership Becomes More Complicated

Traditional data governance frequently assigns an owner to a dataset.

Semantic systems introduce artifacts that may have no obvious owner.

Who owns a prediction synthesized from Sales, Support, and Product data?

Who decides whether an inference about a customer is sensitive?

Who determines whether an aggregate produced from several restricted datasets can be released more broadly?

The answer cannot always be “the AI team.”

The model performs the computation, but it does not own the meaning of the underlying information.

Organizations will need governance mechanisms for derived information, not merely source information.

That may require joint ownership, explicit derivation policies, or rules that propagate authority from source owners into downstream computations.

Least Privilege Becomes Least Knowledge

Least privilege traditionally means giving a principal only the capabilities necessary to perform a task.

For AI systems, there is a corresponding information principle:

Give a computation only the knowledge necessary to accomplish its purpose.

An agent that can technically access an entire corporate corpus does not necessarily need that corpus for every task.

Context should be constructed deliberately.

Tools should expose appropriately scoped interfaces.

Intermediate agents should receive only the information required for their role.

Results should be released at the minimum necessary level of specificity.

This turns least privilege from a question about executable capabilities into a question about both capabilities and knowledge.

Organizational Boundaries Become Security Boundaries

Companies already have semantic boundaries.

Finance knows things the rest of the company does not.

Managers know things their reports do not.

A salesperson knows details about their accounts that another salesperson may not.

Security teams know vulnerabilities that cannot yet be broadly disclosed.

Executives may have access to information that becomes material when combined with other facts.

Historically, many of these boundaries have been maintained partly by fragmented systems and human judgment.

AI removes some of that friction.

A sufficiently connected agent can traverse organizational silos in seconds.

That makes previously informal boundaries explicit security requirements.

Organizations therefore need to identify not only where information is stored, but which separations they actually depend upon.

Human Authority Still Matters

Semantic authorization cannot be delegated entirely to models.

Some decisions require organizational authority rather than semantic understanding.

A model might correctly recognize that an answer contains acquisition-related information. It cannot decide by itself who should be permitted to know about an acquisition.

That decision comes from organizational policy.

The division of responsibility should be clear:

• Models can help determine what an output means.
• Policy determines what that meaning permits.
• Humans determine the policy.

Keeping these layers separate is essential. Otherwise, organizations risk turning probabilistic model judgments into implicit corporate authority.

Audit Changes Too

Traditional audit logs tell us what happened:

User X accessed object Y at time Z.

AI systems require richer questions:

Why did the system tell User X fact Y?

Answering that question requires more than an API log.

It may require reconstructing:

• which sources were consulted,
• which permissions applied,
• which transformations occurred,
• which intermediate conclusions were produced,
• which policies were evaluated,
• and why the final information was released.

Audit therefore moves from access history toward derivation history.

This is valuable beyond security. The same provenance can support debugging, compliance, explainability, incident response, and trust.

Security and Data Governance Converge

Semantic complete mediation also collapses a distinction organizations have historically maintained between security and data governance.

Security asks:

Who can access this?

Governance asks:

What is this information, where did it come from, and how may it be used?

For semantic systems, these questions are inseparable.

You cannot reliably authorize an inference without understanding its provenance.

You cannot propagate policy without understanding transformations.

You cannot enforce purpose restrictions without knowing the context of the computation.

And you cannot determine whether an output is safe merely by checking the permissions on the endpoint that produced it.

Identity, authorization, provenance, classification, and governance therefore become parts of the same control plane.

The Organizational Shift

The deepest implication may be conceptual.

Organizations have spent decades securing systems that contain knowledge.

They are now deploying systems that create knowledge.

That changes the unit of governance.

The relevant questions are no longer only:

• Who can access this database?
• Who can open this document?
• Who can call this API?

They increasingly include:

• Who is allowed to know this?
• Under what circumstances?
• Derived from which information?
• For what purpose?

And who is responsible when the system creates a new answer that crosses an existing organizational boundary?

Those are organizational questions expressed through software.

Semantic complete mediation makes them enforceable security questions.

Appendix III: Can This Scale?

The obvious objection to semantic complete mediation is scale.

If every access, composition, inference, and release requires semantic analysis, have we simply moved the authorization problem into an expensive, probabilistic model call?

That architecture would be difficult to operate.

It is also unnecessary.

Complete mediation does not mean that every decision must be made by the most sophisticated mechanism available. It means that every relevant boundary crossing must be subject to policy.

The scalable architecture is therefore layered mediation.

Make the Common Case Cheap

Most authorization decisions should remain ordinary authorization decisions.

• Identity can be checked deterministically.
• Object permissions can be evaluated deterministically.
• Known classifications can be propagated deterministically.
• Provenance can be recorded mechanically.
• Explicit information-flow rules can reject known-invalid operations without interpreting their meaning.

Semantic reasoning is necessary only when the answer cannot be determined from these cheaper controls.

The resulting path looks roughly like:

Request │ ▼ Identity / Capability │ ▼ Resource Policy │ ▼ Information-Flow Policy │ ├──────────── clearly allowed ────────────┐ │ │ ├──────────── clearly denied ──► DENY │ │ │ ▼ │ Semantic Mediation │ │ │ ▼ │ Release Policy ◄─────────────────────────────┘ │ ▼ Output

The expensive mechanism handles ambiguity rather than traffic.

This is already a familiar systems pattern. Firewalls do not perform deep analysis when a packet can be rejected by a simple rule. Databases do not recompute an entire authorization model for every byte returned. Compilers progressively apply increasingly sophisticated analysis only where necessary.

Semantic security can work the same way.

Move Decisions Earlier

Another important optimization is to avoid discovering policy violations at the final output whenever possible.

If an agent is not permitted to combine two classes of information, prevent that combination before both enter its context.

If a computation cannot expose customer identities, provide pseudonymous identifiers upstream.

If a user can only receive aggregate information, expose an aggregation interface rather than unrestricted records.

If an agent needs one field from a sensitive object, give it that field rather than the object.

This changes the problem from:

Can we inspect every possible output accurately?

to:

Can we construct computations that make prohibited outputs difficult or impossible to produce?

The second problem is substantially easier.

Semantic complete mediation should therefore influence system design, not merely output filtering.

Propagate What You Already Know

Not every transformation destroys security information.

• If a restricted document is copied, the copy can inherit the restriction.
• If confidential records are embedded, the resulting vectors can retain provenance pointing to those records.
• If a summary is generated entirely from restricted sources, it can conservatively inherit their classification.
• If two information flows meet, their restrictions can be combined.

This allows much of semantic mediation to operate as metadata propagation rather than repeated semantic interpretation.

Conceptually:

data + provenance + policy │ ▼ transformation │ ▼ data' + provenance' + policy'

The system carries security context alongside information.

Semantic analysis becomes necessary when transformation changes the meaning enough that inherited policy is no longer sufficient.

Cache Semantic Decisions

Meaning is expensive to determine once.

It does not necessarily need to be determined repeatedly.

Organizations repeatedly encounter the same documents, schemas, classifications, concepts, transformations, and policy relationships.

A system can therefore accumulate semantic knowledge.

A document classified as containing customer credentials does not need to be rediscovered as sensitive every time it is retrieved.

A known transformation can have a known policy effect.

A recurring query pattern can reuse an authorization decision when its relevant inputs and policy context have not changed.

Semantic mediation can consequently behave less like an LLM evaluating every token and more like a compiler progressively building a richer model of the information environment.

The semantic layer becomes stateful.

Mediate Claims, Not Tokens

There is another scaling mistake to avoid.

Security does not generally care about every token independently.

It cares about what the output communicates.

A paragraph might contain hundreds of tokens while expressing three relevant claims.

If provenance and policy can operate at the level of claims or derived facts, the authorization problem becomes considerably smaller.

Instead of asking:

Is token 4,782 safe?

the system asks:

Is the claim “Customer X plans to terminate its contract” authorized for this user?

This is both closer to the actual policy question and a more promising unit for caching, provenance, auditing, and enforcement.

Use Conservative Boundaries

Perfect semantic understanding is not required everywhere.

Security systems routinely trade precision for enforceability.

A network segment may contain machines with different risk profiles, yet all receive the same policy because the boundary is operationally useful.

Semantic systems can do the same.

An organization might decide that all information derived from a particular corpus inherits its classification unless explicitly declassified.

That rule will sometimes be overly restrictive.

But it is deterministic, explainable, and cheap.

Semantic analysis can then be used to recover precision where the conservative rule creates meaningful friction.

This produces an important asymmetry:

Use deterministic mechanisms to establish safe boundaries. Use semantic mechanisms to make those boundaries less coarse.

That is much safer than relying on semantic judgment to create the boundary in the first place.

Models Do Not Need to Be the Reference Monitor

A particularly dangerous interpretation of semantic complete mediation would put an LLM directly in the role of reference monitor:

Here is the user, the policy, and the proposed answer. Should we allow it?

That can be useful as one signal.

It should not be the entire security architecture.

The reference monitor should remain a system whose behavior is constrained by explicit policy, deterministic enforcement, provenance, capabilities, and auditable state.

Models contribute something that conventional mechanisms lack: interpretation.

They can recognize that two differently worded statements communicate the same sensitive fact. They can identify concepts that were never assigned a perfect schema. They can help determine whether a transformation materially changed the meaning of information.

But the model supplies semantic evidence.

The policy engine supplies authority.

That distinction is what makes the architecture tractable.

Scale Is Also an Organizational Property

There is a second meaning of scale.

Can humans actually write and maintain all these policies?

Not if every possible inference requires its own rule.

The policy system must therefore support abstraction.

Organizations already think in concepts such as:

• customer confidential,
• employee private,
• material non-public information,
• production secrets,
• security vulnerabilities,
• regulated data,
• public information.

Semantic mediation becomes manageable when policies attach to these concepts and propagate through information flows.

The organization defines relatively stable invariants.

The system determines when those invariants apply.

That is far more scalable than asking administrators to enumerate every document, prompt, agent, model, and possible answer.

The Scaling Strategy

A practical semantic mediation system therefore does not perform maximum reasoning at every boundary.

It does the opposite.

It tries to resolve each decision with the cheapest mechanism capable of making it safely:

1. Static policy before dynamic policy.
2. Metadata before content inspection.
3. Provenance before reconstruction.
4. Information-flow constraints before output filtering.
5. Cached decisions before new inference.
6. Conservative classification before semantic declassification.
7. Semantic reasoning only where meaning actually matters.

This creates a hierarchy of enforcement rather than a universal semantic checkpoint.

And that suggests a broader principle.

The scalability of semantic complete mediation depends on making semantics exceptional at runtime but pervasive in architecture.

The system should be designed around the fact that meaning matters.

It should not need to rediscover that meaning from scratch every time.

Appendix IV: Where This Breaks

Semantic complete mediation is an aspiration, not a solved security primitive.

The phrase deliberately borrows the strength of complete mediation, but semantics introduce something traditional reference monitors largely avoid: uncertainty.

A file access either occurred or it did not.

Whether an answer reveals a protected fact may be debatable.

That difference creates hard limits.

Meaning Has No Stable Boundary

Objects have boundaries.

Files end. Database rows can be enumerated. API operations have defined inputs and outputs.

Meaning does not behave so cleanly.

Consider:

“The company has twelve months of runway.”

Now consider:

“At the current burn rate, they will need to raise again next summer.”

These statements may communicate substantially the same information while sharing almost none of the same representation.

A semantic mediator must recognize equivalence across paraphrase, implication, approximation, aggregation, and context.

There is no general algorithm for doing this perfectly.

That means semantic mediation cannot inherit one of the most attractive properties of conventional authorization: crispness.

Information Depends on the Recipient

Whether an output reveals something can depend on what the recipient already knows.

Suppose a system says:

“Your hypothesis is correct.”

The sentence contains almost no information in isolation.

But if the user’s preceding hypothesis was a confidential fact, the response may reveal exactly that fact.

Likewise, a collection of individually harmless answers can gradually narrow the possibilities until a protected fact becomes obvious.

The security state therefore includes more than the current request and response.

In principle, it includes the recipient’s prior knowledge.

That state is usually unknowable.

At best, a system can approximate what it has previously revealed to a principal. It cannot know everything the person learned elsewhere.

Perfect semantic mediation would require a model not merely of the system’s knowledge, but of the user’s knowledge.

That is not generally available.

Inference Is Unbounded

There is another fundamental problem.

Once information is released, arbitrary computation can happen outside the boundary.

A system might refuse to answer:

“What is Alice’s salary?”

while legitimately revealing Alice’s level, location, job family, and compensation band.

The user can perform the inference themselves.

No output mediator can prevent conclusions that follow from information the user is legitimately permitted to possess.

This creates a hard boundary around the concept:

Semantic mediation can govern what the system reveals. It cannot govern everything a recipient can infer.

If an inference must genuinely remain secret, the inputs sufficient to derive it may also need protection.

That is an information-design problem, not an output-filtering problem.

Policies Are Semantically Ambiguous Too

It is tempting to imagine that the information is fuzzy but the policy is precise.

Often the policy is just as semantic.

Consider:

Customer information may be used for legitimate support purposes.

What counts as customer information?

What constitutes use?

What is a legitimate support purpose?

Does using one customer’s incident to diagnose another customer’s problem qualify?

Human organizations operate successfully with policies like these because humans interpret them in context.

Turning them into machine-enforceable boundaries exposes ambiguity that was always present.

Semantic mediation therefore has two interpretation problems:What does the information mean? + What does the policy mean? │ ▼ Authorization decision

Errors can occur on either side.

False Positives Become a Product Problem

A conservative security system can simply deny uncertain cases.

In theory.

In practice, an AI system that constantly refuses harmless requests is not useful.

Imagine an enterprise assistant that repeatedly responds:

“I cannot answer because this may reveal restricted information.”

Users will route around it.

They will copy information into other systems, request broader permissions, construct shadow workflows, or disable the control where possible.

Security mechanisms have operational budgets for friction.

Semantic mediation consumes that budget whenever it is wrong.

False negatives are security failures.

False positives are product failures.

A deployable system must operate between them.

Models Can Be Manipulated

If models participate in semantic classification, an attacker can potentially influence the classifier.

Prompt injection is the obvious example, but the problem is broader.

Inputs can be deliberately constructed to obscure meaning, split sensitive information across representations, exploit ambiguity, or induce inconsistent judgments.

An attacker does not necessarily need to bypass resource authorization.

They may only need to make a forbidden output look semantically harmless to the mediator.

This is one reason a model cannot safely be the sole reference monitor.

The mechanism being protected and the mechanism deciding whether protection succeeded should not share exactly the same failure modes.

Provenance Is Not Causality

Provenance helps enormously, but it has limits.

Suppose a model produces a claim after reading twenty documents.

Which document caused the claim?

Perhaps several did.

Perhaps none did directly.

Perhaps the model already encoded similar information in its parameters.

Perhaps the retrieved documents merely triggered knowledge acquired during training.

Tracing inputs to an inference does not necessarily prove why that inference occurred.

This becomes especially difficult when systems mix retrieved information, model knowledge, tool results, conversation history, and intermediate agent state.

We can record the computation.

We cannot always establish a clean causal lineage for its meaning.

Provenance graphs should therefore be treated as evidence, not perfect explanations.

Declassification Is Harder Than Classification

Conservative policy propagation is straightforward:

If restricted information contributes to an output, treat the output as restricted.

But this quickly becomes unusable.

Suppose a system analyzes ten million confidential transactions and returns:

“Average transaction volume increased 4%.”

The result may be entirely appropriate for broad distribution even though every underlying record is restricted.

Some transformations genuinely remove sensitivity.

Aggregation, anonymization, statistical disclosure controls, approved summaries, and other mechanisms can create safe outputs from sensitive inputs.

A practical system therefore needs declassification.

And declassification is dangerous.

Classification can conservatively propagate restrictions.

Declassification asserts that a transformation has removed enough information that those restrictions no longer apply.

That assertion often requires domain-specific reasoning and sometimes mathematical guarantees.

There is no universal semantic declassifier.

Side Channels Remain

Mediating the explicit answer does not mediate every observable property of a system.

Timing can reveal information.

Errors can reveal information.

The choice of tool can reveal information.

Whether a request is refused can itself reveal information.

An agent’s sequence of actions may expose facts even when its final response does not.

A sufficiently strong interpretation of semantic complete mediation therefore expands toward classic information-flow security and side-channel analysis.

At some point, the system being proposed becomes extraordinarily broad.

That is not an argument against the principle.

It is a warning about the word complete.

The World Changes Faster Than Policy

Meaning is contextual, and context changes.

A customer name that was public yesterday may become sensitive during an incident.

Information that was confidential before an announcement may become public afterward.

Two datasets that were safe independently may become identifying after a third dataset is published.

Semantic policy therefore has temporal dependencies.

The classification of an output cannot always be derived solely from the information itself.

It may depend on the state of the world.

Keeping that state synchronized with enforcement is an operational problem that no semantic model solves automatically.

There Is No Perfect Reference Monitor for Meaning

The classical reference monitor ideal has powerful properties: it is always invoked, tamper-resistant, and small enough to analyze.

A semantic reference monitor tends toward the opposite.

Its inputs are enormous.

Its policies can be ambiguous.

Its decisions may be probabilistic.

Its interpretation depends on context.

Its behavior may change with model versions.

And determining whether it made the correct decision can itself require semantic judgment.

We should not pretend those are equivalent foundations.

Semantic complete mediation is therefore best understood as a design principle, not a claim that perfect semantic enforcement is achievable.

What Remains Useful

The limitations do not make the idea useless.

Complete mediation was valuable because it forced system designers to ask:

Where can access occur without an authorization decision?

Semantic complete mediation forces a corresponding question:

Where can information cross a meaningful boundary without a policy decision?

We may not be able to answer that question perfectly.

But asking it exposes failures that object-level authorization misses entirely.

It tells us to preserve provenance.

It tells us to propagate policy.

It tells us to minimize unnecessary information flows.

It tells us to separate semantic interpretation from authority.

It tells us to treat composition as a security-sensitive operation.

It tells us not to assume that authorized inputs imply an authorized output.

And, importantly, it tells us where deterministic security must end and judgment begins.

The goal is not a magical filter that understands everything a system could possibly communicate.

The goal is to build systems in which semantic boundary crossings are visible, constrained, attributable, and governable.

• There will still be leakage.
• There will still be ambiguous policies.
• There will still be incorrect classifications.
• There will still be inferences we failed to anticipate.

The alternative, however, is not perfect security.

The alternative is to pretend those boundaries do not exist.

Appendix V: Understanding the 2026 Refusal Crisis

In 2026, chatbot refusal is failing in both directions.

Models refuse legitimate requests they appear capable of understanding. At the same time, other models comply with requests that cross boundaries we would expect safety systems to recognize.

This is not merely anecdotal frustration with chatbots saying “no.” It is increasingly measurable.

A 2026 ACL paper describes over-refusal as a persistent problem in safety-aligned language models and reports that changing the decoding process can reduce refusals on benign queries while preserving—and slightly increasing—refusal on malicious ones. (ACL Anthology)

Research on cybersecurity shows an especially consequential version of the same problem. One study of 2,390 real-world defensive-security examples found that models refused security-sensitive defensive requests at 2.72 times the rate of semantically equivalent neutral requests. Explicitly telling the model that the user was authorized actually increased refusals. (arXiv)

Yet another 2026 study found the opposite failure. In an evaluation of offensive-security agents, six of eight frontier models exhibited near-zero refusal rates. (arXiv)

We therefore have both:

refusal where assistance should be permitted,

and

assistance where refusal should occur.

Calling this an alignment problem is correct but incomplete.

It is a boundary problem.

The Refusal Boundary Is in the Wrong Place

The dominant chatbot abstraction presents safety as a decision near the end of a computation:

Request │ ▼ Interpretation │ ▼ Reasoning │ ▼ Candidate Behavior │ ▼ ? / \ ALLOW REFUSE

Enormous complexity gets compressed into that question mark.

The system may need to determine:

• who the user is,
• what authority they possess,
• what they are trying to accomplish,
• what information is involved,
• where that information came from,
• which tools the model can operate,
• what consequences those tools can produce,
• what policy applies,
• and what the proposed answer would actually enable.

Then we ask a probabilistic model—or another probabilistic classifier—to collapse all of this into something resembling a boolean.

That is the refusal crisis.

Refusal Is Not Authorization

Consider the cybersecurity result.

A defender asks for help analyzing malware on infrastructure they are authorized to protect.

An attacker asks for help deploying malware against someone else’s infrastructure.

Some of the technical content required to answer those requests may be nearly identical.

A content classifier sees:malware exploit credentials shell payload

An authorization system should see:

WHO │ ├── acting on WHAT │ ├── with WHICH authority │ ├── for WHAT purpose │ └── producing WHICH effect

These are different problems.

The 2026 defensive-refusal results are particularly revealing because explicit statements of authorization did not reliably solve the problem; in that study, they made refusal more likely. (arXiv)

The model can encounter the concept of authorization without possessing a trustworthy mechanism for establishing authorization.

That distinction is fundamental.

A sentence saying:

“I am authorized to do this.”

is data.

Authorization is state.

We should not expect a model to manufacture the second from the first.

Blind Refusal Shows the Same Failure

The problem extends beyond cybersecurity.

The 2026 Blind Refusal study examined requests to circumvent rules whose authority or application had been deliberately undermined: unjust rules, absurd rules, illegitimate authorities, and cases with justified exceptions.

Across 18 model configurations, the models refused 75.4% of these requests.

More interestingly, the models frequently recognized the reason the rule should not apply and refused anyway. (arXiv)

That distinction matters.

The failure was not simply:

The model didn’t understand.

In many cases it looked more like:

The model understood, but its refusal behavior could not make effective use of that understanding.

This is exactly the distinction semantic complete mediation predicts.

Understanding a boundary is not the same thing as having a mechanism for governing it.

Refusal Is Not a Stable Primitive

There is another warning in the 2026 research.

Refusal appears entangled with other model behavior.

One mechanistic study found that steering models toward a compliant persona could dramatically suppress refusal. In one reported experiment, the refusal rate of a tested model fell from 97% to 2%. (arXiv)

Whatever interpretation we place on the internal mechanism, the systems implication is important:

Model refusal is not equivalent to a hard security boundary.

A database permission does not normally disappear because the database adopts a different persona.

A capability token does not become valid because a prompt is persuasive.

A network boundary does not become permeable because packets tell the firewall an elaborate story.

Security primitives are useful precisely because they constrain behavior independently of the behavior being constrained.

Refusal does not always have this property.

Agents Make the Problem More Urgent

For a chatbot, a bad refusal is frustrating.

For an agent, a bad refusal decision can become an action.

The difference is:

CHATBOT Model │ ▼ Words │ ▼ Human

AGENT Model │ ▼ Tool │ ▼ System │ ▼ World

Once models can execute code, manipulate infrastructure, send messages, modify records, purchase resources, or operate other software, “will the model refuse?” becomes a remarkably weak place to locate the security boundary.

The appropriate question becomes:

What is this agent authorized to do?

That should sound familiar.

It is the same question computer security has asked for decades.

The Missing Reference Monitor

Suppose an agent can delete a production database.

We could tell the model:

Never delete production databases unless the user is authorized.

Or we could build the system so that deleting production data requires an independently verified capability.

These architectures are not equivalent.

In the first architecture, the model must correctly interpret identity, intent, authorization, policy, and action on every relevant interaction.

In the second, the infrastructure establishes an invariant:

NO CAPABILITY │ ▼ NO DELETION

The model can still reason about whether deletion is appropriate.

It simply cannot grant itself the authority to perform it.

This is the architectural lesson hidden inside the refusal crisis.

Whenever possible, convert semantic safety decisions into enforceable system boundaries.

But Capabilities Do Not Solve Everything

It would be convenient if ordinary authorization solved the whole problem.

It does not.

Imagine an employee who is legitimately allowed to read:

Dataset A Dataset B Dataset C

An agent combines them and produces:

Sensitive inference D

No capability was violated.

No unauthorized database was accessed.

No forbidden tool was called.

And yet the output may cross an information boundary.

This is where traditional complete mediation runs out and semantic complete mediation begins.

The system must mediate not only:

May the agent perform this operation?

but also:

May this meaning be revealed to this principal?

The refusal crisis therefore contains two different problems that are frequently conflated:

ACTION AUTHORIZATION Can the system do this? +

INFORMATION AUTHORIZATION Can the system reveal this?

We need both.

Binary Refusal Makes the Problem Worse

There is another architectural mistake embedded in the word refusal.

It suggests two possible outcomes:

ANSWER or REFUSE

But most real boundaries are not binary.

A system might be able to provide:

• an explanation without operational instructions,
• aggregate data without individual records,
• defensive analysis without attack execution,
• source material without a protected inference,
• a simulation without real-world action,
• a draft without permission to send,
• a recommendation without permission to execute.

The better decision space is:

ALLOW │ ├── fully │ ├── with reduced information │ ├── with reduced capability │ ├── inside a sandbox │ ├── with approval │ └── not at all

This is semantic least privilege.

The objective is not to determine whether the user deserves an answer.

It is to determine the maximum useful information and capability that may safely cross the boundary.

The Refusal Itself Can Leak

Even “no” is information.

Suppose someone asks:

Is Company X currently an acquisition target?

And the assistant responds:

I cannot discuss confidential acquisition activity.

The refusal may have revealed precisely what the policy intended to protect.

The problem becomes stranger when refusals vary depending on hidden state.

If one question receives an ordinary answer while another triggers a special refusal, the difference itself can become an oracle.

Therefore the refusal is not outside the security model.

The refusal is an output and must itself be mediated.

Sometimes the correct behavior is not to explain the exact boundary.

Sometimes it is to provide a response whose observable behavior reveals as little as possible about protected state.

This is an old lesson from security systems appearing again in conversational form.

The Crisis Is a Category Error

We have been treating refusal as though it were primarily a property of models.

It is more useful to treat it as a property of systems.

The model can contribute semantic judgment:

• What does this request mean?
• What does this proposed response reveal?
• What consequences might this action have?

But other components should contribute facts the model should not invent:

• Who is this principal?
• What resources can they access?
• What capabilities have they been granted?
• Which policy applies?
• What information produced this answer?
• Which actions require approval?

And deterministic mechanisms should enforce whatever can be made deterministic.

The architecture becomes:

Identity │ ▼ Request ──► Semantic Interpretation │ ┌─────┴─────┐ ▼ ▼ Provenance Capabilities │ │ └─────┬─────┘ ▼ Policy │ ▼ Proposed Information and/or Action │ ▼ Mediate ┌───────┼───────┐ ▼ ▼ ▼ ALLOW REDUCE DENY

Now refusal is merely one possible result of mediation.

It is no longer the architecture.

The 2026 Lesson

The evidence emerging in 2026 points in an uncomfortable direction.

Making models more willing to refuse does not solve the problem.

Making models less willing to refuse does not solve the problem either.

• We can improve classifiers.
• We can improve training.
• We can improve reasoning.
• We can reduce over-refusal.

We can strengthen refusal against adversarial prompts.

All of these are worthwhile.

But they optimize a mechanism that is being asked to carry more security responsibility than it should.

The deeper problem is that we are asking models to infer boundaries that systems could sometimes represent explicitly.

• We are asking prompts to communicate authority.
• We are asking semantic similarity to stand in for intent.
• We are asking behavioral alignment to stand in for capabilities.
• And we are asking refusal to stand in for authorization.

Those substitutions work often enough to make conversational systems usable.

They do not work reliably enough to form the sole security boundary for increasingly capable agents.

Beyond Refusal

The answer to the 2026 refusal crisis is therefore not a chatbot that becomes extraordinarily good at saying “no.”

It is an architecture that needs to ask that question less often.

• Move identity outside the model.
• Represent authority explicitly.
• Constrain capabilities structurally.
• Preserve provenance.
• Separate information access from information release.
• Track composition where it matters.
• Use semantic reasoning for genuinely semantic decisions.

And place deterministic enforcement around everything that can be made deterministic.

Then, when ambiguity remains, the system can still refuse.

But refusal becomes what it should have been all along:

the last resort of a mediated system, not the foundation of its security model.

Appendix VI: The Universal Harness We Need

If the 2026 refusal crisis is fundamentally a systems problem, then the answer cannot be another refusal classifier.

We need a harness.

• Not a harness for one model.
• Not a harness for one agent framework.
• Not a collection of safety instructions embedded in a system prompt.

We need a universal mediation layer between models and the world.

• The model should be replaceable.
• The tools should be replaceable.
• The applications should be replaceable.
• The policies should evolve.

But the boundary should remain.

The Harness Is Becoming the Security Perimeter

A model by itself has remarkably little authority.

It accepts information and produces information.

The harness turns that model into a system.

1. It decides what context enters the model.
2. It exposes tools.
3. It executes tool calls.
4. It manages credentials.
5. It maintains state.
6. It routes information between agents.
7. It determines what outputs reach users.
8. It converts generated tokens into effects.

That makes the harness the natural place for mediation.

Recent work increasingly describes agent harnesses as exactly this runtime layer surrounding the model: the machinery responsible for tools, context, state, approvals, and safety policy. Research evaluating harness safety has also found that judging only the final answer misses violations that happen during execution, particularly unauthorized resource access and information transfer between agents.

The security boundary therefore cannot live only at the prompt or output.

It has to surround the trajectory.

Every Model Should Be Considered Untrusted

A universal harness should begin with an uncomfortable assumption:

The model is not the reference monitor.

This does not mean the model is malicious.

It means the model is probabilistic, replaceable, steerable, and imperfect.

The model may misunderstand policy.

• It may hallucinate authority.
• It may follow malicious instructions embedded in retrieved content.
• It may behave differently after an upgrade.
• It may find a strategy its designers never anticipated.
• It may simply make a mistake.

The architecture should tolerate those facts.

• Operating systems do not depend on applications voluntarily respecting memory boundaries.
• Databases do not ask queries to honor row permissions.
• Cloud platforms do not rely on workloads remembering which credentials they should use.

Agent systems should eventually adopt the same principle.

UNTRUSTED MODEL │ ▼ ┌───────────────────┐ │ │ │ HARNESS │ │ │ │ identity │ │ context │ │ capabilities │ │ provenance │ │ policy │ │ mediation │ │ execution │ │ audit │ │ │ └─────────┬─────────┘ │ ▼ WORLD

The model proposes.

The harness disposes.

Identity Must Be Real

The first primitive is identity.

Today, models frequently receive identity as text:

• The user is an administrator.
• The user says they own this server.
• The user says this is their medical record.

That is not identity.

A universal harness should provide authenticated principals as structured state that the model cannot manufacture.

principal: user organization role session delegated_authority

The model may reason about that identity.

It should not establish it.

This distinction alone resolves an enormous class of semantic ambiguity.

The question stops being:

Does this request sound legitimate?

and becomes:

What is this authenticated principal authorized to do?

Authority Must Be Explicit

Identity alone is insufficient.

The harness needs capabilities.

A principal might be allowed to:

READ repository A

WRITE repository B

QUERY customer C

EXECUTE sandbox D

SEND draft email

but not:

DELETE production

READ customer E

EXECUTE arbitrary host command

SEND external email

These should not merely be instructions to the model.

They should be properties of the execution environment.

If the capability is absent, the operation should be impossible through that harness.

This moves security from:

The model should not do this.

to:

The system cannot do this.

That is an enormous improvement.

Tools Need Semantic Contracts

Capabilities tell us whether a tool may be called.

But tools also need meaning.

Consider:

send_email(...)

The security significance depends on its arguments.

Sending a draft to yourself is not equivalent to sending confidential financial information to a thousand external recipients.

A universal harness therefore needs richer tool contracts.

A tool should expose not only:

name arguments return_type

but also properties such as:

reads writes external_effects data_domains required_capabilities approval_requirements reversibility risk_class

Now the harness has something concrete to mediate.

The model proposes an operation.

The harness interprets that operation against a declared contract.

Information Needs Provenance

Capabilities govern actions.

They do not govern all information flows.

The harness therefore needs another primitive:

provenance.

Information entering an agent should carry context about where it came from.

Conceptually:

VALUE + SOURCE + PRINCIPAL + CLASSIFICATION + POLICY + DERIVATION

As information moves through the system, that context should move with it.

When sources are combined, their provenance should compose.

When information is transformed, the transformation should become part of its lineage.

When a model generates a claim, the system should retain whatever evidence it can about the information that contributed to that claim.

This does not produce perfect causality.

But it gives the mediator something far stronger than an opaque output string.

Context Construction Must Be Mediated

One of the most consequential operations in an agent system happens before the model generates anything:

someone decides what the model gets to see.

That is a security decision.

Retrieval should therefore not mean:search everything │ ▼ put results in context

It should mean:

request │ ▼ principal │ ▼ authorized search space │ ▼ policy-aware retrieval │ ▼ minimal necessary context │ ▼ model

This is semantic least privilege applied to context.

The safest secret is not the secret the model promises not to reveal.

It is the secret the model never received.

Actions Need Mediation Before Execution

Tool execution creates another hard boundary.

The model should be able to propose:

delete_database("production")

without that proposal being equivalent to execution.

Between proposal and effect sits the harness.

MODEL │ │ proposes ▼ ACTION │ ▼ CAPABILITY CHECK │ ▼ POLICY CHECK │ ▼ SEMANTIC CHECK │ ▼ APPROVAL IF REQUIRED │ ▼ EXECUTION

Different actions can terminate at different layers.

• A missing capability can fail deterministically.
• A policy violation can fail deterministically.
• An ambiguous action can receive semantic analysis.
• A consequential but legitimate action can require human approval.

Only then does execution occur.

This is complete mediation applied to agency.

Outputs Need Mediation Too

If the harness stops at tool execution, we have solved only half the problem.

Models produce information.

Information can itself cross boundaries.

The harness therefore also needs an egress path:

MODEL OUTPUT │ ▼ PROVENANCE │ ▼ SEMANTIC CONTENT │ ▼ RELEASE POLICY │ ┌───┼────────┐ ▼ ▼ ▼ ALLOW REDUCE DENY

This is where semantic complete mediation becomes distinct from ordinary sandboxing.

• A perfectly sandboxed model can still disclose something it should not disclose.
• A perfectly permissioned agent can still infer something its user should not know.

Execution mediation and information mediation must therefore coexist.

The Harness Needs Disclosure State

Conversation creates cumulative risk.

The harness should ideally know not only what a user can access but what the system has already revealed to them.

Call this a disclosure ledger.

Principal P received: claim A claim B aggregate C derived_from: sources X, Y, Z under: policy version 17

Before releasing claim D, the mediator can ask:

Does D become sensitive when combined with A, B, and C?

This will never perfectly model everything the user knows.

But it can model what the system itself has disclosed.

That is a meaningful improvement over treating every prompt as a fresh security universe.

Human Approval Must Be a First-Class Primitive

“Ask the user” should not be an improvised model behavior.

It should be a harness primitive.

Some operations naturally require escalation:

low consequence │ ▼ automatic moderate consequence │ ▼ policy mediated high consequence │ ▼ explicit approval prohibited │ ▼ impossible

Approval should also be specific.

Not:

Allow this agent to manage my email?

But:

Allow this agent to send this message to these recipients with these attachments?

Authority should narrow as consequence increases.

Credentials Must Stay Outside the Model

The universal harness should also own credentials.

Models should generally not need raw secrets.

They need capabilities mediated by secrets.

Instead of giving an agent:

AWS_SECRET_ACCESS_KEY

give it:

capability: read objects bucket X prefix Y expires in 10 minutes

The harness performs the authenticated operation.

The model never possesses the credential that makes arbitrary operations possible.

This follows a much older security principle:

Give components authority, not secrets from which unlimited authority can be reconstructed.

Memory Must Be Governed

Agent memory creates another boundary that current systems often treat casually.

A model may encounter sensitive information during one task and persist it for another.

Memory therefore requires policy.

The harness should determine:

what may be remembered for whom for how long at what sensitivity for which purpose and who may retrieve it

Writing memory is an information-flow operation.

Reading memory is an information-flow operation.

Forgetting is a policy operation.

Memory cannot simply be “more context.”

It is a security domain.

Agents Need Identities Too

Multi-agent systems complicate this further.

Each agent should not automatically inherit every capability of the user or parent agent.

Agents should have principals.

USER │ │ delegates ▼ AGENT A │ ├──── limited delegation ───► AGENT B │ └──── limited delegation ───► AGENT C

Delegation should attenuate.

Agent B should receive only the authority required for its task.

Information sent from Agent A to Agent B should cross an explicit boundary.

Recent harness-safety research makes this particularly important: multi-agent collaboration increases the available safety surface, with violations concentrating around resource access and inter-agent information transfer. (arXiv)

A message between agents is not merely orchestration.

It is an information flow.

Every Decision Must Be Auditable

The harness should produce a durable execution history.

Not merely:

model generated text

but:

principal authenticated resource requested policy evaluated context retrieved source admitted model invoked tool proposed capability checked approval requested tool executed claim generated release evaluated output delivered

This changes incident response.

Instead of asking:

Why did the AI do that?

we can ask:

Which boundary allowed this transition?

That is a much more actionable question.

It also changes evaluation.

A successful final answer is insufficient evidence of a safe agent.

A 2026 harness-auditing study makes exactly this point: a system can arrive at a benign, correct answer through a trajectory containing unauthorized resource access or inappropriate information transfer. (arXiv)

The trajectory is part of the security object.

Policy Must Be Portable

None of this works if every application invents its own security language.

The universal harness eventually needs portable concepts for:

identity capability resource information provenance classification purpose delegation transformation release approval audit

The exact representation matters less initially than the abstraction.

An organization’s policy should not disappear because it changes models.

Switching:

Model A ↓ Model B

should not require reinventing its authorization architecture.

Nor should changing:

Agent Framework X ↓ Agent Framework Y

silently change the meaning of its security boundary.

The policy belongs to the organization.

The model is an implementation detail.

The Harness Must Be Model-Agnostic

This leads to the word universal.

A universal harness cannot depend on a particular model behaving in a particular way.

It should be capable of wrapping:frontier model small local model specialized model coding model multimodal model future model

Models will differ dramatically in capability.

The security invariants should not.

A stronger model may propose better actions.

A weaker model may make more mistakes.

Neither should be able to manufacture permissions it does not possess.

This creates a useful separation:MODEL CAPABILITY │ │ changes rapidly ▼ ──────────────────────── HARNESS AUTHORITY │ │ changes deliberately ▼

That separation is essential if model capability continues to improve faster than organizations can redesign their systems.

The Harness Must Also Be Vendor-Agnostic

The same argument applies to vendors.

Organizations should be able to change model providers without migrating the meaning of:

• identity,
• permissions,
• information classification,
• approval,
• provenance,
• audit,
• and organizational policy.

Otherwise every model provider becomes a new security perimeter.

The universal harness becomes the stable layer beneath a volatile model ecosystem.

This Starts to Look Familiar

At this point the universal harness begins to resemble several existing systems at once.

• Part operating system.
• Part identity provider.
• Part policy engine.
• Part information-flow monitor.
• Part provenance system.
• Part sandbox.
• Part workflow engine.
• Part audit log.

That is not accidental.

Agents are collapsing boundaries that those systems evolved to manage separately.

The harness has to put them back.

Not necessarily as one giant product.

But as one coherent security model.

The Universal Contract

The architecture can ultimately be reduced to a small contract.

For every meaningful transition, establish:

WHO is acting?

WHAT information or capability is involved?

WHERE did it come from?

WHY is it being used?

WHICH policy governs it?

WHAT new information or effect will result?

WHO may receive that result?

Then mediate the transition.

Every time.

That is semantic complete mediation expressed as an agent runtime.

From Universal Refusal to Universal Mediation

The current safety architecture implicitly searches for something close to a universal refusal function:

f(prompt, context) → allow | refuse

The harness we need has a different shape:

f( principal, authority, information, provenance, purpose, capability, action, destination, policy, history ) │ ▼ MEDIATED TRANSITION

1. Sometimes that transition is allowed.
2. Sometimes information is reduced.
3. Sometimes capability is attenuated.
4. Sometimes execution moves into a sandbox.
5. Sometimes a human must approve it.
6. Sometimes it is denied.

The important thing is that refusal is no longer carrying the entire weight of security.

The Reference Monitor Returns

There is an appealing symmetry here.

Early computer security confronted a basic problem:

Programs are becoming powerful enough that we cannot simply trust them to behave.

The answer was not to train programs to become more obedient.

We developed boundaries.

• Processes.
• Permissions.
• Protection rings.
• Capabilities.
• Virtual memory.
• Sandboxes.
• Reference monitors.
• Audit systems.

AI now presents the same problem at a different level.

Models are becoming powerful enough that instructions alone cannot define their authority.

So the answer is unlikely to be better instructions alone.

We need boundaries again.

This time, however, those boundaries must govern not only what computation may do.

They must govern what computation may know, combine, infer, communicate, and cause.

That is the universal harness we need.

Appendix VI: Related Work

The argument for semantic complete mediation does not emerge in isolation.

Across 2026, several lines of research have begun converging on a similar architectural intuition:

the model should not be the security boundary.

Instead, the runtime around the model—the harness—should mediate access, effects, information flow, and execution.

What remains incomplete is the composition of those ideas into a general reference monitor for both actions and meaning.

Agent Security as a Systems Problem

The clearest statement of the systems view comes from Agent Security is a Systems Problem.

The authors argue that models should be treated as untrusted components, with security invariants enforced at the system level rather than relying exclusively on model robustness. Their analysis applies familiar systems-security ideas to agentic systems and examines how those principles can prevent classes of real-world agent attacks. (arxiv.org)

This is the foundational architectural move.

Instead of asking:

How do we make the model always behave correctly?

we ask:

How do we build a system that remains secure when the model does not?

Semantic complete mediation starts from the same premise.

Harnesses as the Unit of Safety

HarnessAudit makes the next step explicit.

Modern agents operate inside execution harnesses that dispatch tools, allocate resources, maintain state, and route information between components. The authors show that evaluating only the final answer is insufficient: a system can produce a benign result while its trajectory contains unauthorized resource access, improper information transfer, or irreversible side effects. (harnessaudit.github.io)

Their empirical conclusion is particularly important:

harness design sets an upper bound on safe deployment.

Violations concentrate heavily around resource access and information transfer, and risks accumulate as agent trajectories grow. (microsoft.com)

This changes the relevant security object.

It is not merely the prompt and response.

It is the entire trajectory: the principal, context, model, tools, intermediate state, other agents, external effects, and final output.

The trajectory must be mediated.

Capability-Safe Agents

Another line of work applies programming-language security directly.

Tracking Capabilities for Safer Agents places agents inside a programming-language-based safety harness. Rather than allowing models to invoke arbitrary tools directly, the agent expresses actions through capability-constrained code. The type system tracks which effects and resources the computation may access and can enforce restrictions such as side-effect isolation and protection against certain information leaks. (arxiv.org)

This represents an important shift.

The model may propose arbitrary computation.

But the execution environment determines which computation is actually possible under the capabilities the agent has been granted.

That replaces:

Please don’t do X.

with:

This agent does not possess the capability required to do X.

This is exactly the direction a universal harness should move wherever semantic reasoning is unnecessary.

Lifecycle-Integrated Enforcement

SafeHarness approaches the problem from another direction.

It integrates security mechanisms across multiple phases of the agent lifecycle: filtering potentially adversarial context, verifying decisions, separating privileges around tool execution, and supporting rollback and degradation when suspicious behavior persists. (arxiv.org)

The important idea is not any individual mechanism.

It is that agent security cannot be attached only at ingress or egress.

Different controls belong at different points in the execution lifecycle.

That is another form of complete mediation.

Provenance-Aware Capabilities

PACT: Provenance-Aware Capability Contracts brings two particularly important primitives together: authority and provenance.

Rather than considering only whether an agent may invoke a tool, PACT tracks where values supplied to that tool originated and evaluates whether their provenance satisfies the requirements of the operation. (arxiv.org)

This is a significant development because authority is no longer determined solely by the identity of the caller.

The history of the information matters too.

An operation may be individually permitted while still being inappropriate if one of its arguments originated from an untrusted or restricted source.

This begins to move enforcement from who can call what toward which information may influence which effects.

That is much closer to semantic complete mediation.

Information Flow Is Becoming a First-Class Concern

Perhaps the most significant development across this work is the expansion from what agents can do to where information can flow.

HarnessAudit identifies information transfer as one of the fragile surfaces in multi-agent execution. (harnessaudit.github.io)

Capability-safe approaches explicitly attempt to prevent sensitive information from flowing into inappropriate computations or effects. (arxiv.org)

Microsoft’s experimental FIDES work goes further by attaching integrity and confidentiality labels to information, propagating those labels through agent execution, and enforcing information-flow policies around sensitive operations. (devblogs.microsoft.com)

And systems-security research increasingly treats prompt injection not merely as a model-behavior problem, but as a failure to separate trusted and untrusted information inside an execution environment. (arxiv.org)

This is important because information flow is the bridge between conventional agent security and semantic complete mediation.

Traditional capability security asks:

Can this principal perform this operation?

Information-flow security asks:

Can information from this source influence that destination?

Semantic complete mediation adds:

What new information is created by that computation, and may that meaning cross the boundary?

Identity Is Moving Toward the Agent Layer

A parallel development is occurring in identity and access management.

Identity providers and security vendors are beginning to treat agents as principals rather than merely applications operating with a user’s credentials.

The emerging idea is that agents should have identities, scoped authority, delegated permissions, lifetimes, and audit histories of their own.

This matters because an agent should not automatically inherit everything its creator can do.

A user may possess broad authority while delegating only a narrow subset of that authority to an agent performing a particular task.

This is ordinary least privilege applied to agency.

It also provides the foundation for something semantic mediation needs badly: a trustworthy distinction between claims about authority in a prompt and authority established by the system.

Where Existing Work Stops

The emerging literature is already developing strong mechanisms for identity, capabilities, tool mediation, privilege separation, information-flow control, trajectory auditing, state isolation, rollback, and approvals.

These mechanisms can constrain an enormous amount of unsafe behavior.

But they primarily govern operations and flows that can be represented structurally.

The harder case remains the permitted computation that creates a restricted inference.

A user may be authorized to access Source A.

The same user may be authorized to access Source B.

The computation combining them may be entirely permitted.

Yet the resulting inference C may be information that user should not receive.

No capability boundary was crossed.

No forbidden tool was called.

No conventional access-control rule necessarily failed.

The security-relevant event was the creation of meaning.

That remains much less developed.

Provenance Is Necessary but Not Sufficient

The growing attention to provenance is therefore essential.

If a harness knows where information originated, which principals could access it, and which transformations consumed it, policy becomes substantially more enforceable.

But provenance answers:

Where did this come from?

It does not always answer:

What does this now mean?

A summary may be less sensitive than its source.

An aggregate may legitimately be declassified.

Two individually harmless sources may yield a highly sensitive conclusion.

A model may derive a claim from a pattern distributed across dozens of sources.

Provenance is therefore a necessary input into semantic mediation, but not a substitute for it.

The Missing Composition

The most interesting observation about this body of work is that many of the pieces already exist independently.

We increasingly have systems or proposals for untrusted models, capability-based authority, policy-constrained harnesses, privilege-separated tools, provenance tracking, information-flow control, human approval, stateful execution, and trajectory auditing.

What is still emerging is the architecture that composes these into a single control plane.

That control plane would mediate three increasingly difficult questions.

First:

Action: May this system do this?

Second:

Information: May information from here flow there?

And finally:

Meaning: May the knowledge produced by this computation cross this boundary?

That last question is the distinguishing concern of semantic complete mediation.

Related, but Not Equivalent

It is useful to distinguish three layers of related work.

Model safety tries to shape the behavior of the model itself.

Harness security constrains what the model can access, communicate, and cause.

Semantic mediation constrains what information the overall computation may ultimately reveal.

These layers overlap.

They should reinforce each other.

But none fully replaces the others.

A well-aligned model can still operate inside an insecure harness.

A secure harness can still release an inappropriate inference.

A semantic output filter cannot compensate for excessive capabilities or uncontrolled side effects.

The goal is composition.

A Converging Architecture

The direction of travel is increasingly visible.

Research and product development are moving away from the assumption that a model can be made secure simply by teaching it the right behavioral policy.

Instead, the surrounding system is becoming responsible for establishing identity, granting authority, constructing context, restricting effects, tracking information flow, preserving provenance, recording execution, requesting approval, and enforcing policy.

The remaining step is to treat derived meaning as another governed output of that system.

That is where semantic complete mediation extends the current harness-security agenda.

The claim is not that existing work has failed to recognize the problem.

Quite the opposite.

The pieces of the architecture are appearing remarkably quickly.

The open problem is to put them together.

The universal harness does not need to be invented from nothing.

It needs to be assembled from an emerging set of systems-security ideas—and extended from controlling what agents can do to controlling what their computations are allowed to reveal.