Architecting Authority in Intelligent Systems
Trust Is Infrastructure
Correct identity does not make an action correct. Intelligent systems need authority that is bounded, explainable, revocable, and auditable.
The decision brief“A consequential action needs two proofs: why the system chose it, and why the system was allowed to take it.”
The decision brief
A practical starting point
Audit authority, not identity alone: for every consequential action, require evidence of the choice and evidence of the right to execute it.
- Distinguish identity verification, authority and behavioural correctness.
- Identify the questions to ask before connecting AI to consequential tools.
- Connect protection with continuity, recovery and accountability.
Central question
What does your system trust without realizing it?
The opening scene
The invoice the agent was told not to send
A user writes to an AI agent: “Review the invoice. Do not send anything.” The system reads it, verifies the user, uses valid credentials, reaches an authorized tool, and sends the invoice. The identity is correct. The access is valid. The action is wrong. In a few seconds, the scene separates a lawful route to a tool from the purpose for which that route was opened.
Security has often begun with “Who are you?” We authenticate, issue credentials, assign permissions, and treat the remainder of the path as understood. An agent adds a new actor: software that interprets an intent, selects an operation and a tool, and may replan while executing. Identity becomes the beginning of the question because a known principal can still be represented by the wrong action.
The question that follows the audience home is not whether agents are dangerous in the abstract. It is: what does your system trust without realizing it? A retrieved passage, a tool description, an outside message, or stale memory may influence a system that holds real authority. The architectural problem is the path by which influence reaches action.
What once seemed sufficient: identity
Authentication establishes who is making a request, and authorization describes what that principal may do. Intelligent systems add a third question: which operation did the system choose inside that space? A session can be authenticated and a tool permitted while the selected operation still exceeds the user’s intent.
Imagine an employee entering a building with the right badge and finding keys to every room on the desk. The badge proves who entered; it does not explain why every door has become available. Computational authority should not arrive as one undivided block followed by an instruction to the model to be careful.
Inside the machinery of authority
Least privilege leads to the confused deputy: a program with legitimate power that exercises it for the wrong requester or context. The pattern returns with more reach when untrusted text can influence a system that has tools. The core problem is larger than a malicious sentence. It is the mechanism that lets information acquire the force of authority.
A stronger design scopes power to a task, time window, policy, and named operations. It makes grants revocable and decisions inspectable. “Human in the loop” adds little if the person sees an opaque plan and presses a ceremonial button. The information they receive, the decision they retain, and their power to stop or change the action define meaningful oversight.
Two Proofs of Action
The talk proposes Two Proofs of Action as a design lens. The first asks why the system selected this action. That proof follows data, retrieval, memory, inference, and context. The second asks why the system was entitled to take the action. That proof follows the principal, delegation, scope, policy, and expiry.
The framework keeps the decision story separate from the authority story so that neither can hide behind the other. A system may explain its choice without holding the right, or hold valid authority while misunderstanding the task. For a consequential action, both paths should be visible, inspectable, and interruptible.
When the surface of authority changes
One version may examine an agent that reads mail and uses a calendar. Another may examine multi-agent systems, tool protocols, workload identities, or a software supply chain in which the model itself has become a component. The frontier moves, while the root question remains: how can legitimate intent become legitimate authority without giving untrusted influence the right to act?
The final action is simple to state and difficult to practice: audit authority, not identity alone. Select one consequential operation in your system. Write down why it would be chosen and why it would be permitted. If the two answers cannot be separated and evidenced, you have found an architectural gap before it becomes an incident.
Explore the idea
The two-proofs test
Choose one consequential action, then separate what explains the decision from what grants the power.
The key
Which tool or capability can change the world outside the model?
All perspectives
The key
Which tool or capability can change the world outside the model?
The principal
Whose authority is being exercised, and how was that identity established?
The task
Which scope, duration, and operations does the actual intent justify?
The action
Can you prove the reason for choosing it separately from the right to take it?
An illustrative scene to explore
Windows into the idea
Questions that open another door
Is this a talk about prompt injection?
Prompt injection is an important route by which untrusted information may shape a decision, but it is not the whole world. The deeper question is how to prevent influence from becoming authority and how to keep permission to read separate from permission to execute what was read.
Does Zero Trust solve this?
It supplies a strong basis in continuous verification and reduced assumptions. An agent still adds task interpretation and operation selection. The connection may be verified and access authorized while the operation exceeds the original intent.
Does bounded authority make an agent less useful?
Well-designed limits make capability usable with confidence. They grant what the current task requires and create an explicit, auditable way to expand it instead of relying on permanent power with an unknown edge.
When is human approval real?
When the person understands the decision, sees the necessary evidence, has time to judge, and can stop or alter the action. A button alone does not establish that judgment remains human.
What should I carry back to work?
See every intelligent action as two stories: a decision story and an authority story. Begin with one consequential operation and ask for its two proofs separately.
The idea’s bookshelf
Works that illuminate the subject and offer paths for further reading.
- The Protection of Information in Computer Systems
An MIT author-hosted rendering of the 1975 Proceedings of the IEEE paper, covering architectural protection principles including least privilege and complete mediation.
- The Confused Deputy: (or why capabilities might have been invented)
A 1988 ACM paper explaining how a program can exercise legitimate authority for the wrong requester or context.
Who it is designed for
- Cybersecurity, risk and technology leaders
- Systems architects and identity or platform teams
- Researchers and practitioners in intelligent-system security
When it fits
For organisations expanding agent use or reconsidering permissions and trust across their technology ecosystem.
What it does not promise
Not an offensive-security course, an audit of the host organisation, or a guarantee against incidents.
One central idea. Depth to match the room.
These formats are proposals. Readiness, duration and interaction are confirmed for each invitation. These are the languages of the website descriptions. Live delivery languages and interpretation arrangements are confirmed separately for each engagement.