Intelligence Is Not Authority: Designing the Trust Boundary for Agentic AI

From Satya Nadella’s insider risk argument to agent identity, delegation, and an independent control plane

Intelligence proposes. Authority permits. Infrastructure enforces.

The previous post looked at agent identity as four separate questions — who connected, which program this is, who it represents, and whether this action is approved — and then specifically called out a few things that mechanism does not solve as things stand: a stolen token still works, authority expires mid-task, the audit log is written by the agent itself, and the whole thing has no accepted standard yet.

This post carries on from those boundaries. The question shifts from “what should a single tool call be checked against” to “where should the layer doing the checking live, and why can it not be under the agent runtime’s control.”

When models start holding real execution capability

In Models as Insider Risks in the Super Intelligence Era, Satya Nadella raises this security problem worth paying attention to: enterprises are giving models that cannot be fully explained access to sensitive data and the ability to perform critical operations. What is cited here is that article’s theme; the system design discussed below is my own takeaway and engineering inference, not a product blueprint Satya proposed.

Traditional software is not necessarily as easy to debug as he suggests, and distributed systems least of all. But an LLM’s decision cannot be attributed cleanly to one human-written code path. Once a system evolves from a chatbot into an agent that can deploy code, restart services, and modify databases, the risk escalates from “a wrong answer” into “a real system side effect.”

Treating an agent as an insider risk is a pretty good architectural analogy: it does not require assuming the agent is malicious, and it does not take “the model will behave correctly” as a precondition for authorization. That makes least privilege, separation of duties, audit, revocation, and containment matter a great deal more. Models and human insiders still differ fundamentally, so not every insider risk management practice can be applied wholesale.

The core separation: execution plane and authority control plane

Figure 1 — The agent runtime proposes an action; the tool gateway verifies it against independent authority services at the execution boundary. The orange dashed lines represent authorization interactions, not a requirement that all traffic pass through the control plane in sequence.

The agent execution plane owns the planner / LLM, state / context, executor, and checkpointing. It describes and governs how the agent gets work done, and it should have no ability to create or widen its own authority.

The independent authority control plane owns identity, delegation, policy, credential brokering, approval, audit, and revocation. Independence is an important security property, not necessarily a deployment shape: infrastructure can be shared, but a model-controlled component must never be able to bypass or tamper with enforcement.

There is something worth noting here: the normal data path for a tool call is runtime → tool gateway → target API. The gateway obtains an authorization decision from the authority services; the authority control plane is not a data relay for every tool call.

Identity is not authority

As I mentioned in my Agent Identity Primer, the question that matters most is not “what is this agent called” but “who authorized this agent, within what window, to do what to which resource?”

Suppose the agent produces:

{"tool":"reboot_device","resource":"device-123","requested_by":"alice"}

Even if the policy engine correctly decides whether alice may reboot the device, there is still something to check: where did alice come from? If that value came from context the LLM can control, then the so-called security decision is built on untrusted input.

Human identity, agent / workload identity, delegated authority, and per-action authorization all need to be kept distinct. An agent being able to prove which workload it is does not mean it inherits all of the user’s permissions.

Figure 2 — The credential broker verifies the delegation and its scope, then issues a constrained execution capability; the tool gateway verifies again before a sensitive operation. The diagram shows logical interactions rather than a specific OAuth flow.

In practice this can use scoped, short-lived credentials, token exchange, broker-managed sessions, or capability-based authorization. What matters is not one particular token format, but that authority has a trustworthy origin, explicit resource / action / audience / lifetime constraints, and can be revoked or re-verified when needed.

Identity proves who is acting. Delegation establishes on whose authority. Authorization decides whether this action is allowed.

Policy enforcement has to happen at the real execution boundary

Figure 3 — Checks at the planner stage are not enough to protect production. Every sensitive tool invocation has to rest on verification at a trusted enforcement point.

Checking permissions only at the planner stage breaks easily — the plan changes, something retries, another tool path exists, or an SDK gets called directly. Real enforcement has to happen before the side effect occurs, re-verifying caller, delegation, resource scope, approval, and limits according to the risk of the operation.

But an MCP tool gateway is not the only boundary. If the agent can run a shell, use a cloud SDK, or holds other credentials, you still need cloud IAM, network policy, secrets controls, and target-side authorization to close off bypass paths.

Observability is not interpretability

Even if we log prompts, model output, tool calls, policy decisions, and execution results, that cannot mean we have fully explained the model’s internal decision mechanism. But production security does not have to wait for mechanistic interpretability to mature before it can deliver execution traceability.

What matters is being able to answer these questions: who initiated the task, which agent executed it, which delegation supplied the authority, which policy allowed the operation, which tool caused the side effect, and how the result is verified.

Satya’s discussion is also a reminder to build independent controls, verifiability, audit, and incident response. But the concrete architecture still has to be designed around the actual risk, system boundaries, and organizational responsibility — a single set of high-level principles should not be treated as a complete reference architecture.

A kill switch is not containment

Stopping an agent does not pull back secrets that have already leaked, and it does not automatically reverse a data deletion or an external operation that has already been sent. Real containment has to cover three phases: shrinking the blast radius before execution, monitoring and interrupting during execution, and recovery and audit afterwards.

Long-running agents have an additional problem: if a user revokes permission after the task has entered the queue, does the worker need to re-verify when it resumes? The answer depends on the authorization model and the semantics of the operation, but it cannot rest on a long-lived credential acquired at the start. Durable execution has to come with durable authorization semantics, accounting for revocation propagation, TOCTOU, idempotency, and compensating actions.

Identity does not guarantee intent either

Even when Alice really did authorize the agent to reboot device A, the agent can still be influenced by prompt injection or bad context into performing an inappropriate operation inside a legitimate scope. Which means verifiable delegation is a necessary condition, not the whole of agent safety. High-risk operations may additionally need transaction-specific approval, semantic validation, and impact-aware controls.

By the same token, an external policy engine can be misconfigured; that calls for policy tests, threat modeling, red teaming, and an independent audit process.

Beyond that, something came to mind naturally as I read Satya’s tweet: Microsoft’s commercial investment in identity, security, governance, and AI platform is genuinely compatible, product-wise, with an insider risk narrative. That is worth factoring in when evaluating its recommendations, but commercial incentive alone does not refute an architectural claim.

Conclusion — Intelligence Is Not Authority

The core challenge for agent infrastructure ahead is not only making agents smarter. It is letting enterprises safely grant them real-world execution capability without having to fully trust the model’s behavior.

An agent runtime should be good at planning, state management, and durable execution; authority infrastructure should supply trustworthy identity, delegation, scoped credentials, independent enforcement, audit, and revocation. The two can integrate tightly, but the security boundary has to be guaranteed as one the model cannot cross on its own.

Intelligence proposes. Authority permits. Infrastructure enforces.

References

• Satya Nadella — Models as Insider Risks in the Super Intelligence Era
• Agent Identity Primer
• RFC 8693 — OAuth 2.0 Token Exchange
• NIST SP 800-207 — Zero Trust Architecture
• SPIFFE

All diagrams and implementation recommendations here are independent engineering interpretations, not representations of a vendor-prescribed architecture.