Discussion on "Governed Intelligence: Separating Capability, Authority, and Verification in AI Systems"

ahmed younis · 2026-08-19T12:39:15.628Z

AI systems are becoming increasingly capable of reasoning, planning, using tools, and taking actions. But capability alone is not enough. For systems that may operate inside financial, enterprise, res

Separating capability, authority, and verification is the right decomposition, and authority is the one teams under-specify. I apply the same split when I vet MCP servers before trusting them in an agent, checking what a tool is allowed to do separately from what it can do, and wrote it up here: kartiknvjk.hashnode.dev/how-i-evaluate-mcp-server…. Where do you enforce the authority boundary, inside the agent or outside it?

Thanks Kartik — our design principle is that the consequential authority boundary should sit outside the agent.

The agent may reason about and request an action, but it should not be able to authorize itself. For consequential operations, we prefer deterministic policy enforcement, narrowly scoped credentials/capabilities, and explicit approval gates at the tool or execution boundary.

The prompt can describe intended behavior, but it should never be the security boundary.

That separation becomes especially important with MCP and other externally supplied tool surfaces, where tool capability and execution authority must remain independently constrained.

The separation between capability, authority, and verification is the right framing. Most agent frameworks conflate all three: the agent that can run a tool is implicitly authorized to run it, and the tool's response is treated as verified fact. That breaks in production when an agent hallucinates a syntactically valid tool call.

The fail-closed design is harder than it looks. Most frameworks don't have a default deny at the identity level. The agent's context is mutable, and an instruction-injection attack can override the 'only call this tool' rule. The fix is to move the authority boundary from the prompt to the credential: the tool should reject calls that arent cryptographically scoped to a specific session and action. That way, even if the agent's instructions are overridden, the tool still enforces the original policy.

One thing to watch: who grants the authority and how does it survive across agent restarts? If authority is a one-time grant in the agent's context window, it evaporates on token limit reset. A durable session identity that persists authority across runs makes the pattern production-ready.

Strong point. We agree that the enforcement boundary has to move below the prompt layer. Model instructions are mutable context; they should not be the final authority mechanism.

For consequential actions, our architectural direction is an external deterministic authorization layer with narrowly scoped credentials or capabilities, so compromised reasoning cannot expand execution rights.

I’d make one distinction on persistence:

Persistent identity should not imply persistent authority.

A durable agent identity can survive restarts and be re-associated with an authoritative delegation or policy record. But the resulting authority should remain scoped, expiring, independently revocable, and auditable.

On restart, the system should reconstruct current authority from trusted external state rather than inherit ambient privilege from previous model context.

Persistent identity, without persistent ambient privilege.

Search Hashnode

Governed Intelligence: Separating Capability, Authority, and Verification in AI Systems

Responses(4)