Satya Nadella published a short piece on X on October 10 titled “Models as Insider Risks in the Super Intelligence Era.” Read it in full; it takes five minutes. Compressed, the argument runs:
We could trace a traditional system’s behavior to a specific code path. We cannot do that for a frontier model. Yet we are handing models our most sensitive data and the authority to act on it.
Stacking models to check models does not fix this. You get an opaque model inside an opaque orchestrator, watched by another opaque model. Nested black boxes.
The way out is old. Enterprises have handled powerful insiders for decades: establish identity, limit privileges, log activity, draw containment boundaries. Treat the model the same way. Not because it is malicious, but because any capable actor with access can make mistakes or be compromised.
So the controls that govern what a model can access and do must sit outside the model, where the model cannot tamper with them. In his words, “separate the supply of intelligence from the authority over it.”
Seven principles follow: model diversity, observe everything, verifiability, independent controls, independent auditability, containment, incident disclosure.
His closing point is that the system to trust is the one that needs to trust the model least.
He is writing about agents in general. I want to apply it to one specific place where agents already touch sensitive data in production today: the analytics tier. A business user asks a question. An agent turns it into a query. The query runs against the warehouse. Thousands of companies shipped some version of this in the last two years.
The analytics tier is already an insider-risk problem
Most “chat with your data” deployments work the same way. The model gets the schema, writes SQL, and something executes it. Hold that against the principles.
Access control lives in the prompt. The model is told which tables it may use and which rows it may see. A program that can be talked out of its permissions is exactly what the 1970s security principle he cites forbids. The control is inside the thing it is supposed to control.
The evidence is the SQL the model wrote. Plausible, a hundred lines long, and reviewable by nobody who asked the question. Observable in theory. Not in practice.
Nothing refuses. Ask a model for a join the schema cannot support and it writes one that looks supported. A wrong number arrives in the same format as a right one, and the business user cannot tell them apart. That was always the failure mode that worried me most.
Verification is another model. A second model reads the first model’s SQL and says it looks fine. Nested black boxes, exactly as described.
The semantic layer was invented for a different problem: one definition of revenue across every dashboard. It turns out to be the containment architecture he is describing, provided it is built a particular way. Most are not.
What containment looks like at this tier
Take the model out of the SQL business. The model writes a spec instead: these measures, these dimensions, this filter, on behalf of this user. A deterministic planner resolves the spec against a governed model and returns SQL, or refuses. The model never sees a credential and never sees a row.
Map that to the principles.
Independent controls. What the agent can reach is defined by the semantic model in git and the security context on the request. The planner enforces both. The prompt cannot widen them, and neither can the model.
Observe everything. The spec is the human-readable evidence. Thirty tokens anyone on the team can read: store net paid and catalog net paid by date, asked on behalf of Dana in EMEA ops. The SQL is the second artifact, derived from the first by a program, with no model attesting to anything.
Verifiability. The same spec against the same model yields the same statement, byte for byte. That makes query generation testable the way code is testable: golden files, diffs in CI, a failing build when a model change alters the SQL.
Containment. The planner never connects to the warehouse. It holds the shape of the data and nothing else. The only action in its action space is “produce a statement.” Execution stays inside your network, under the controls you already have.
Model diversity. The contract is a JSON document. Swap the model, keep every control.
Refusal. Not one of his seven, but the consequence of them. A spec the model cannot satisfy returns an error naming what could not be resolved, not a query that happens to parse. A benchmark TypeDB published last month found the same effect from the other direction: the query language whose wrong queries fail loudly ended up ahead once a retry loop was added, because a model can only fix the mistakes it can see.
Concretely. Ask for a store measure and a catalog measure by date, which is where a model double-counts through two fact tables:
store net paid, catalog net paid, dateThe planner returns two aggregates joined after grouping, never one join before it:
WITH cat AS (
SELECT sum(cs_net_paid) AS catalog_net_paid, d_date
FROM catalog_sales JOIN date_dim ON cs_sold_date_sk = d_date_sk
GROUP BY d_date
), store AS (
SELECT sum(ss_net_paid) AS store_net_paid, d_date
FROM store_sales JOIN date_dim ON ss_sold_date_sk = d_date_sk
GROUP BY d_date
)
SELECT store.store_net_paid, cat.catalog_net_paid,
COALESCE(cat.d_date, store.d_date) AS date
FROM store FULL OUTER JOIN cat ON cat.d_date = store.d_date
Ask for store net paid by warehouse name, where no join path exists, and you get a 422 that names the measure it could not reach. No SQL. The model cannot hallucinate a column, because it never writes one.
Where I think I was wrong
Last week on Hacker News I wrote that a semantic layer is “definitely not useful for developers/data engineers anymore” and belongs in the analytics harness for business users. I built Strata on that belief, and I pulled 0sql out of Strata on that belief: semantics are for the people and agents asking questions at the top of the stack. Developers can write the SQL themselves and read it afterwards, so they never wanted the abstraction.
Satya’s framing changes the question. The insider is not the business user. The insider is the model. And the model is now in the application tier and the data platform tier too, writing the operational query in the support tool, the transform in the pipeline, the data-quality check in the CI job. Those are developers’ tiers. The agent can write that SQL as well as a developer can. Reading it afterwards is the part that stopped scaling.
So there is probably a class of use cases lower in the stack where the same contract belongs: anywhere an agent composes a read over governed data and a human needs to see, in a few lines, what it asked for. I do not know yet how far down that goes. Transactional writes are a different problem and I am not claiming them. Perhaps we will see.
What to ask of the layer
If you are putting an agent in front of a warehouse, these are the questions the insider framing makes me ask of whatever sits between them.
Does the control sit outside the model, or in the prompt?
Is the request the agent makes short enough for a human to read, and kept?
Does the same request always produce the same SQL?
Does the layer hold your credentials, your rows, or a cache? If it connects to the warehouse and returns rows, it sits inside the boundary it is supposed to enforce.
Does it refuse, or does it guess?
Can you swap the model without touching any of the above?
A layer that answers those the right way is doing for agents what badge readers and audit logs did for people. Satya is right that none of this is new. We just had not pointed it at the model.
Disclosure: this architecture is what we pulled out of Strata and run as an API at 0sql. The model is yours, the planner is hosted, the data never leaves your network. You can try the agent version with no account at 0sql.io/try.