Separation of Powers for Cognition: The Sensor Sees, the Model Reasons, the Human Signs

Every enterprise AI conversation eventually reaches the same wall. The high-value use case needs the model to understand the data warehouse, the finance workbooks, the BI estate, the mailbox — and the security review needs the model to have no access to any of them. Most programmes resolve the tension in one of two bad ways. They starve the AI, and the project produces a chatbot that knows nothing. Or they feed it, wiring the model to production systems through connectors and hoping behavioural guardrails hold — and inherit a governance problem that ends the programme at its first incident review, or its first honest audit.

There is a third way, and it is not a compromise between the two. It is a different constitutional design. I built it into a production system this year — an evidence workbench that reads a Power BI estate and client spreadsheets and compiles them into an evidence-backed readiness assessment — and the architecture that emerged generalises far beyond that one system. This article is the design in full: the separation of powers, the sensor that implements it, the declassification contract that governs what the model may see, and the manifest that lets a third party certify the whole thing.

The compact form of the doctrine takes four lines:

The sensor sees but does not decide.
The model reasons but does not touch.
The human authorises and owns the consequence.
The code makes only the authorised transition real.

Everything else in this piece is the engineering that makes those four lines enforceable rather than aspirational.

The default architecture concentrates power in one branch

Start with the failure shape, because you almost certainly own a copy of it. On my phone, I can hand an AI assistant a Gmail connector, and it goes straight to the raw email — all of it, every private thread. Look at what the OAuth grant actually says. Google's own scope catalogue describes the Gmail scope as "Read, compose, send, and permanently delete all your email from Gmail," and the read-only variant as viewing all your messages and settings; the Drive scope covers "all of your Google Drive files."¹ There is no scope for "the three threads relevant to this task." The atomic unit of grant is the container — the whole mailbox, the whole drive.

Vendors mitigate this behaviourally, and to be fair, they say so plainly: Anthropic's connector documentation notes that Claude only reads mail and creates drafts, does not send, and "retrieves the minimum information needed."² But notice the structure of that promise. The policy narrows what is used. The credential still spans the mailbox. When the behavioural layer fails — a jailbreak, a prompt injection, a model update that shifts behaviour — the blast radius is the grant, not the promise.

And the behavioural layer does fail, for a reason the UK's National Cyber Security Centre states with unusual bluntness: "An LLM inherently cannot distinguish between an instruction and data provided to help complete the instruction."³ A model reading attacker-authored text cannot reliably refuse to obey it. Security researchers have named the fatal combination the "lethal trifecta": access to private data, exposure to untrusted content, and a channel to communicate externally — any agent holding all three is exploitable.⁴ Under the connector model, that is not a misconfiguration. It is what the agent is, by design.

Corporate deployments are currently copying this consumer shape with corporate data — warehouse connectors, SharePoint connectors, CRM connectors, all terminating in the model's context window. OWASP's LLM risk register now has a name for the pattern: excessive agency, rooted in "excessive functionality; excessive permissions; excessive autonomy."⁵ The recommended mitigations read like a confession that the architecture was wrong to begin with: limit extensions to the minimum, limit permissions to the minimum, require human approval for high-impact actions.

Here is the diagnosis underneath all of it: the default architecture gives one component — the probabilistic one — the seeing, the reasoning, and the acting. All the discretion and all the privilege, concentrated in the single branch of the system you can least predict and least inspect. Political theory worked out centuries ago what happens when one actor holds all the powers. Software security worked it out fifty years ago: Saltzer and Schroeder's 1975 principles demand least privilege — "every program and every user of the system should operate using the least set of privileges necessary to complete the job" — and separation of privilege, the two-keys-to-unlock rule.⁶ We simply stopped applying the doctrine when the program became fluent.

The privilege inversion

The fix is not to make the model more trustworthy. It is to notice that trustworthiness and capability are different axes, and to allocate access by predictability, not by intelligence.

The deterministic sensor can see more but decide less. The AI can reason more but see less. The human can authorise because they own the consequence.

This is the privilege inversion, and it runs against every instinct the demo economy has trained into us. The most semantically capable component — the model — receives the narrowest access, precisely because it is the least predictable. The least intelligent component — a deterministic extractor, a few hundred lines of reviewed Python — receives the broadest read access, precisely because it is constrained, inspectable, and incapable of improvising. A read-only audit function cannot be talked into anything. It has no instruction channel to inject. It does the same thing every run, and you can prove it.

That produces a genuine separation of powers — four actors, each holding exactly one kind of authority:

Read the table by columns and the design principle falls out: discretion and privilege move in opposite directions. The components with the most judgment (model, human) touch the least raw reality. The components with the most reach (sensor, compiler) exercise no judgment at all. No single actor both sees the raw world and changes it. The model proposes; it owns neither the truth it reasons from nor the consequence it recommends. This is Saltzer and Schroeder's separation of privilege applied to cognition: the dangerous transition needs multiple keys — the model's proposal, the human's signature, the compiler's validation — held by mechanically different actors.⁶

I have written elsewhere about the two leashes that bound a corporate agent — a compiled worldview above the model grounding what it believes, and authority infrastructure below it constraining what it may execute. This architecture adds the actor that framework never named: the privileged sensor that manufactures the world the leash is made of. Between raw reality and the model's beliefs sits a component with more access than the model will ever hold — and it deserves first-class constitutional treatment, because it is where the inbound risk actually lives.

The sensor is the model's retina

What does the sensor actually do? It is tempting to call it a privacy scrubber, and that undersells it badly. The sensor manufactures the world the model is allowed to perceive.

CLIENT SYSTEMS AND RAW DATA
        ↓
AUDITED DETERMINISTIC SENSOR
  client-local · read-only credentials
  allowlisted operations · no model access
        ↓
SAFE SEMANTIC PROJECTION
  structure · relationships · formulas
  metadata · masked or omitted values
  source coordinates
        ↓
MODEL COGNITION
  interpretation · matching · significance
  questions · proposed findings
        ↓
HUMAN DECISION SURFACE
  accept · modify · reject · request evidence
        ↓
DETERMINISTIC COMPILATION OR ACTION

The perception chain here — world, then probe, then representation, then context, then cognition — is one I have developed at length in the Agent's Retina: a model never "looks at" a thirteen-gigabyte database; something must engineer a view, because raw machine-scale reality is not a model input. But there is a critical difference in trust regime. The Retina's instruments are forged by the agent at runtime — disposable probes for the question of the moment, operating inside whatever access the agent already has. The sensor in this architecture is the opposite object: compile-time, reviewed, and privileged. It holds credentials the model must never hold, so it cannot be improvised. It must be written before the engagement, reviewed like the security-relevant software it is, and versioned so you can say exactly which eyes were used for which observation.

The sensor does three jobs simultaneously, and the deep insight of this whole architecture is that they are the same transform:

• Security: remove what the model must not see.
• Perception: preserve what the model needs to understand.
• Compression: make the resulting world small enough to reason over.

Enterprise teams assume a trade-off: more data access means smarter AI; less access means safer but dumber AI. The sensor breaks the assumption, because raw business data is simultaneously sensitive and cognitively terrible — billions of values, opaque file formats, hidden sheets, cached fragments, presentation noise, volumes no attention window can hold. The transform that strips the sensitive values is the same transform that raises the semantic density of what remains. The model receives less information by volume and more information by meaning.

AI should see less data and understand more of the business.

A production specimen: the workbook that became evidence

Here is the sensor that taught me the pattern, running today inside FDE BI, my evidence and architecture-reconciliation workbench for Power BI engagements. Client spreadsheets arrive as declarations of a target architecture. The naive path — hand the workbook to the model — is doubly wrong: the workbook is full of client-confidential values, and its raw OOXML form is cognitive sludge.

Instead, a deterministic extractor — XLSX.evidence v2 — takes the workbook bytes and renders a text-native evidence packet. In: literal text coordinates, formulas, sheet and table structure, defined names, comments and links, validation rules, connection metadata, and bounded indicators for Power Query, pivots, embedded models, VBA and package security. Out: every ordinary numeric, date and Boolean value — they never enter the model packet. Secrets are masked. Opaque binary bodies are fingerprinted, not dumped. And every category reports its own epistemic state: found, absent, truncated, or detected without a full decoder — so the model knows what the sensor could not see, instead of hallucinating over the gap.

The result: the model can determine that a workbook specifies a customer-profitability model, requires dimensions absent from the current BI estate, and declares fourteen target measures — without ever seeing the client's actual customer revenue. It received the meaning-bearing architecture of the workbook and none of its commercially sensitive contents. In the retained blind-comparison runs, a model working only from that packet and an isolated view of current-state knowledge — fixture names and expected answers hidden until after results were saved — correctly resolved fourteen of fourteen mappings on the matching workbook, ten direct and three not-found on the partial workbook, and returned eight not-founds on the complete-miss workbook. The blindfold is the point: the harness proves the packet carries enough meaning to reason with, and the citation validator proves every finding traces to workbook coordinates the sensor actually emitted.

Compiled cognition: AI is used twice

Now the objection every security lead should raise: "That extractor sounds like a serious piece of software. Spreadsheet archaeology, OOXML internals, connection-string handling, redaction — who is writing all this?"

AI wrote it. And that is not a hole in the architecture — it is the second half of the architecture.

The system uses AI in two distinct physical states. At design time, a frontier model — with broad knowledge of Excel's on-disk format that no single engineer economically holds — investigates the structures, writes the extractor, writes its tests, and revises it under my review. At runtime, a live model reasons over the packets the extractor produces. Between the two states, the intelligence undergoes a phase change:

probabilistic synthesis
    ↓  inspected code
    ↓  tested behaviour
    ↓  versioned sensor
    ↓  repeatable evidence

The deployed sensor no longer improvises. It repeats a reviewed observation policy, identically, every run. I've taken to calling this compiled cognition: there's AI in a live form, interpreting evidence and proposing findings — and there's a solidified form of AI in the deterministic code. The solidified form is prior intelligence crystallised into a mechanism, not a model making runtime choices.

Why does the distinction carry so much weight? Because it changes which governance regime applies. A live model making decisions inside a privileged environment requires a governance apparatus most organisations have never built — non-deterministic outputs, no pre-deployment review, no meaningful rollback. A piece of deterministic code, whoever authored it, slots into governance machinery that has existed for twenty years: code review, testing, version control, change management, rollback. The organisation does not have to trust a live model with raw access merely because AI helped author the program. It has to review a program — a thing its existing institutions already know how to do. I've called this move governance arbitrage: route the AI's value through the artefact path, where the review gates already exist, rather than the live-decision path, where they don't.

The model can be clever; the organisation can remain conservative.

There is precedent for this posture in the least likely place: the platform vendor's own tooling. Microsoft's metadata scanning for Fabric — the vendor's governance mechanism for the Power BI estate — is exactly a deterministic, credential-gated sensing surface. The scanner APIs extract "item name, owner, sensitivity label, applied tags and endorsement status," and for semantic models "table and column names, measures, DAX expressions, mashup queries, and so forth"⁷ — structure, not rows. The API requires a Fabric administrator or service principal, and is rate-limited to five hundred requests an hour.⁸ Even the deep metadata is an explicit escalation: two tenant switches, the second dependent on the first, separately gate detailed semantic-model metadata and DAX/mashup expressions.⁹ Credential-gated, allowlist-shaped, switch-controlled, rate-limited: Microsoft ships the sensor posture for its own estate. The architecture in this article extends that posture to everything the vendor's scanner cannot see — and puts a certifiable contract around it.

The Proof-Carrying Sensor

"It's Python and it looks read-only" is not a security argument. A read-only database account proves the sensor cannot update the database. It does not prove the sensor cannot run a ruinously expensive query, expose ten million rows in its output, write sensitive material to a log, or transmit a packet somewhere it shouldn't. If the sensor is going to hold the broadest read access in the constitution, it must carry proof commensurate with that privilege.

So ship every sensor as a Proof-Carrying Sensor — the deterministic extractor delivered with a manifest that makes its safety claims checkable:

With that manifest in hand, a third-party reviewer is no longer being asked to vouch for a vibe. They can certify a concrete claim:

"This exact version can execute only these read operations, emits only this schema, cannot mutate the source, and has no route to export anything else."

That sentence is the product. It converts an unanswerable trust question — what might the AI do with our data? — into an answerable engineering question: what can this artefact, at this hash, actually emit? The first question has stalled six-month security reviews across the industry. The second is a week's work for a competent reviewer, and the answer is reusable: the same certified sensor runs across engagements under different client-local credentials, accumulating trust the way audited libraries do. Clients who would never grant a model warehouse access will grant an audited artefact read-only credentials — because they are not being asked to trust intelligence; they are being asked to trust a mechanism, reviewed through institutions they already operate.

Semantic declassification: the contract, not the scrubber

The manifest bounds what the sensor can do. A second contract governs what the packet may contain — and this is where most privacy thinking goes wrong, because most privacy thinking is subtractive. Redaction asks: what should we remove? The right question is declarative: what world should the model inhabit, for this purpose? Nothing is simply "AI-safe" in all situations; the precise question is safe for which principal, for which purpose, to answer which class of question. I call the discipline semantic declassification — a declared model-view contract with ten dimensions:

For the workbook packet, the contract's classification runs in three bands. Default allow: object types, counts, stable identifiers, data types, relationship topology, structural fingerprints. Conditional: names, descriptions, formulas, DAX, M queries, source identifiers, lineage, owners, paths — admitted when the declared purpose requires them, because names like Termination_Reason and formulas encoding commission rules are themselves disclosures. Deny by default: row values, samples, credentials, connection strings, caches, embedded payloads, and hidden content unrelated to the task.

The band structure encodes the rule that matters: the model-visible packet is explicitly allowlisted, never produced by removing the obviously sensitive things. A blocklist fails open — everything you didn't think of leaks. An allowlist fails closed — everything you didn't declare stays out. When the boundary guards against a component that cannot distinguish instructions from data,³ failing closed is the only defensible default. And note who enforces the contract: the deterministic sensor, not the model. The model cannot be its own inbound airlock for the same reason a defendant cannot be their own judge.

One more clarification, because a colleague of mine put the instinct memorably: strip the private data, reshape the rest for the machine, get rid of the governance nonsense, and turn the AI up to 11. Half of that is right. The correct version is: do not remove governance — remove governance from the model's discretion. The governance is all still there. It has been compiled into the extraction allowlists, the schema, the ACL inheritance, the redaction tests, the drill-down gates and the run receipts — which is exactly why it stops feeling like a committee attached to every prompt. Governance as a compile-time property is what makes "up to 11" safe at runtime.

Metadata-first, not metadata-safe

The instinct that started me down this path was that metadata might be the general case of what is safe for AI to read — pull the structure, the schema, the topology, and leave the values behind. As a default starting posture, that instinct is right. As a safety guarantee, it is wrong, and the gap between those two statements needs to be marked in the doctrine, because "we only shared metadata" is on its way to becoming the enterprise AI equivalent of "we only kept the hashes."

Microsoft's own documentation makes the case against complacency. The Document Inspector exists because workbooks silently carry: document properties including author user names; comments; hidden rows, hidden columns that contain data, and hidden worksheets; "hidden names that might store hidden data in the workbook"; invisible objects; links to other workbooks and inactive external connections; "cached data for PivotTables, PivotCharts, slicers, timelines, and Cube formulas that might not be visible"; VBA modules and user-defined functions; and custom XML.¹⁰ Every one of those is "metadata" by a casual definition. Several of them are payloads. A cached pivot fragment is data. A hidden name can store anything. A column named Salary next to a column named Employee discloses the schema of something sensitive even with every cell blank.

Australian privacy law then closes the trap from the regulatory side. The OAIC's guidance is explicit that identifiability is contextual and combinatorial: "Some information may not be personal information when considered on its own. However, when combined with other information held by (or accessible to) an entity, it may become 'personal information'" — and information holdings are dynamic, so "the character of information can change over time."¹¹ The regulator's test is about the combination available to the holder, not the field in isolation. A model-visible graph of authors, lineage, timestamps and relationships can cross the identifiability line without containing a single conventional identifier — which is precisely why the declassification contract must cover edges and relationships, not just values, and why "safe" must be declared per purpose rather than asserted of a data type.

So the principle gets a deliberately double-edged name: metadata-first, not metadata-safe. Begin with structure, topology and relationships — it is the lower-risk candidate representation and usually the more cognitively useful one. Then run it through the same allowlist contract as everything else, because a safe harbour it is not.

Bronze is an evidence tier, not a permission tier

Every serious version of this architecture keeps an immutable evidence store — I use the lakehouse word bronze — holding original workbook bytes, audit outputs, screenshots, model transcripts, decision receipts. Everything the sensors observed, content-addressed and preserved. Which raises the question that quietly wrecks otherwise good designs: the packet gives the model a pointer to the bronze evidence behind a claim — so can the model follow the pointer?

No. Storage tier and access tier are separate axes. Bronze answers "what evidence exists and can a human auditor reach it?" It does not answer "what may the model read?" A pointer is addressability, not permission. Conflating the two turns your evidence store into a back door: the model couldn't see the raw workbook in the packet, but it could ask for the bronze object containing it.

What the model legitimately has is agency over the question. When it needs more resolution — "do these three measures depend on an undocumented source?" — it does not get a credential and a query console. It requests a specific approved view, and a deterministic sensor decides how the raw system may answer: source types, relationship paths, expression fingerprints, masked endpoints, evidence identifiers, known absences. The model never writes arbitrary SQL against production, never holds the warehouse password, never receives unrestricted protocol access.

The AI can decide what it needs to know. An approved deterministic sensor decides how the raw system may answer.

And when no suitable sensor exists? That is the moment the connector architecture reaches for improvisation — let the model query production, just this once. The constitutional answer is a protocol instead: the missing view is identified; design-time AI drafts a new sensor with its tests and manifest; human and security review certify it; the signed version deploys; later runs inherit the new sense. The sensing surface expands the way case law expands — deliberately, with review, leaving a record — rather than the way shadow IT expands. Runtime authority never grows silently. This is the same discipline SiloOS applies to identity data, where agents reason over tokens and a trusted proxy alone rehydrates real values at the execution boundary — generalised from values to entire worlds.

MCP is not broken. Model-facing MCP is the layer error

Now the correction this argument owes the protocol everyone is deploying. The Model Context Protocol is genuinely useful, and nothing above is an argument against it. Anthropic's framing is accurate: a universal, open standard replacing fragmented per-source integrations.¹² But read the specification's own scope statement: MCP standardises how applications "share contextual information with language models, expose tools and capabilities to AI systems," over JSON-RPC between hosts, clients and servers.¹³ Connection and invocation. The spec is equally clear about what it does not do: "MCP itself cannot enforce these security principles at the protocol level" — consent, authorisation, access controls are explicitly delegated to implementors.¹³ Its own security-best-practices document catalogues what happens when implementors don't: token passthrough is "explicitly forbidden"; broad up-front scopes create an "expanded blast radius"; proxy deployments invite confused-deputy attacks.¹⁴

In other words: the protocol standardised the plug, not the content — a distinction I drew in BI for Soft Data and will not re-derive here. The layer error is treating a standardised plug as though it were a safe cognitive interface. gmail.search, warehouse.query, crm.get_record — these are container operations. They expose reach. They do not manufacture a suitable observation.

A connector gives the model access. A sensor gives the model an engineered perception.

Which yields a placement doctrine rather than a verdict on the protocol:

The funny thing about my own production use of MCP is that I used it by taking it away from the model. FDE BI's Power BI interrogation runs through Microsoft's Power BI MCP tooling — handed to deterministic Python, not to the agent. It's meant for agent access; I turned it into deterministic code. The protocol became a source adapter beneath the sensor: Python controls the interrogation, produces repeatable audit evidence, and passes bounded results into the cognitive system. The protocol as transport; the code as retina. Anthropic's own engineering guidance has converged on the same shape from the efficiency direction — presenting MCP servers as code APIs so that "intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return"¹⁵ — a pattern I've examined in detail elsewhere. They reach it for tokens; I reach it for governance. Both roads end at the same architecture: MCP belongs below the sensor, not mistaken for the sensor.

The two airlocks

Put the pieces together and the model sits between two airlocks:

PRIVILEGED BUSINESS WORLD
  raw email · documents · warehouses · workbooks
        ↓
█ INBOUND AIRLOCK — perception
  proof-carrying sensors · declassification contracts
  what reality may become model-visible
        ↓
COMPILED, GOVERNED SEMANTIC WORLD
        ↓
FRONTIER COGNITION — turned up as far
as the economics justify
        ↓
PROPOSAL / FINDING / DECISION PACKAGE
        ↓
█ OUTBOUND AIRLOCK — authority
  human judgment · policy checks · deterministic gates
  what model output may become real
        ↓
APPROVED CONSEQUENCE

The inbound airlock decides what reality may become model-visible. That is this article's territory: the sensor, the manifest, the contract. The outbound airlock decides what model output may become real — human authorisation for material findings, deterministic gates for everything else, receipts throughout. That side I have built out as Two Leashes and Decision Authority Infrastructure, and I will not re-derive it here; what matters for this piece is that the two airlocks are symmetric jurisdictions of the same constitution, and each dismantles one leg of the lethal trifecta.⁴ The inbound airlock removes raw private-data access: the sensor sees it; the model sees the declassified packet. The outbound airlock removes free external communication: the code makes only the authorised transition real.

Between the airlocks, you can be aggressive — genuinely aggressive, batch-deep, fifteen-minutes-per-question aggressive — because the boundaries hold regardless of what the model does. That is the point the safety framing always misses: this is a capability architecture. The airlocks are not there to slow the AI down. They are what makes it safe to turn the AI up to 11. One discipline note carried over from the task-world work: "up to 11" never means dumping the whole compiled world into a context window — cognition is compiled per purpose, from the governed layer, for this task, under this access scope. Compile the business. Compile the task. Then maximise cognition.

Maximum cognition. Minimum privilege. Explicit authority.

What I can and can't claim

Honesty about the evidence base, because an architecture article that hides its sample size is exactly the kind of ungoverned claim this doctrine exists to prevent. The separation of powers described here is running in one production-shaped system — FDE BI — with one hardened sensor and retained blind-comparison runs against synthetic fixtures. The declassification contract has been worked through in earnest for one packet type, the workbook. Adjacent systems of mine apply the same constitution to different worlds — a business-advisory deployment where deterministic collectors read business channels nightly and PII is tokenised before anything reaches a model, and a development-knowledge compiler where deterministic preparation feeds model comprehension under gated mutation — but that is convergent design by the same architect, not independent replication. n=1, stated as n=1. The claim on offer is architectural, not statistical: these properties hold by construction, the way a read-only credential's properties hold by construction. What n=1 cannot yet tell you is the maintenance economics of a sensor library at scale, or how the contracts fare under a hostile client audit. I intend to find out.

And the red team deserves the last word before the conclusion, because a "safe" packet can still leak. Edges leak: the relationship between an unnamed executive, a redundancy programme and an acquisition can be more sensitive than any value in the graph. Inference leaks: formulas and lineage encode business rules; a schema can disclose the existence of what it describes; the OAIC's combination test applies to everything the holder can reach, including what your packet lets them derive.¹¹ Aggregation leaks: enough innocuous structure, joined, re-identifies. The declassification contract narrows these channels and the red-team tests in the manifest probe them — they do not abolish them. Anyone who tells you their representation is categorically safe is selling redaction with better marketing. The honest posture is a declared contract, adversarial tests against it, and a standing assumption that the contract has a hole you haven't found yet.

The constitution, restated

The industry's default architecture asks one component to be the eyes, the mind and the hands — then asks a policy document to keep it honest. Fifty years of security doctrine,^6,16 the protocol specs' own disclaimers,¹³ and every whole-mailbox OAuth grant on your phone¹ say the same thing about how that ends.

The alternative is a constitution. A deterministic sensor with the broadest read and no discretion, shipped as a proof-carrying artefact a third party can certify. A model with the deepest reasoning and the narrowest world, inhabiting a packet declared by contract rather than scraped by connector. A human who signs because the consequence is theirs. And a compiler that makes only the signed transition real. Discretion and privilege moving in opposite directions — which is what lets you maximise cognition without maximising blast radius. This is the inbound half of the architecture whose commercial consequences — the services that cannot exist without the machine — I mapped in AI-Constituted Services; this piece is the organ that capstone deliberately left to be built.

Compile reality before cognition. Compile authority before action.