Foundations of Verifiable Delegation
Foundations of Verifiable Delegation
- separate capability, access, and authority in plain language
- explain why agentic systems need bounded delegation before action
- describe the basic principal, delegate, verifier, and evidence model
Mandaitor is easiest to understand when you separate three ideas that are often mixed together: capability, access, and authority. A system has capability when it can technically perform an operation. A caller has access when it can authenticate and reach a protected resource. A delegate has authority only when a principal has intentionally permitted a specific action under specific conditions.
This distinction is central for agentic AI. A tool-using agent may be able to call a payment API, update a CRM record, file a report, send a message, or request data from another system. None of those capabilities automatically proves that the agent should perform the action. Mandaitor focuses on the missing question: does this actor have a specific, bounded, verifiable mandate for this action, resource, and context?
Delegation is the act of allowing another actor to perform work on behalf of a principal. Verifiable delegation adds machine-checkable evidence so that systems can evaluate the delegation before action and reviewers can inspect it afterward.
Capability
The system, tool, or agent has the technical ability to perform an operation, such as sending a message or updating a record.
Access
The caller has credentials, network reachability, and permissions that let it interact with a protected service or dataset.
Authority
A principal has granted bounded permission for a specific delegate, action, resource, time window, and context.
Why is access alone not enough for an agent that can call business tools?
- Because access proves only that the tool can be reached, not that the action is allowed for this principal and context.
- Because agents should never use APIs.
- Because every tool call must be manually approved forever.
Reveal answer
Access proves reachability and authentication. Mandaitor adds the delegated-authority question: whether this concrete actor may perform this concrete action for this principal under the mandate boundary.
The simplest mental model
The beginner-friendly model is a triangle. A principal owns the original authority. A delegate acts on the principal's behalf. A verifier checks whether a proposed action fits the delegated boundary. Mandaitor provides the infrastructure that turns this relationship from an informal promise into a verifiable control point.
| Term | Plain-language meaning | Mandaitor interpretation |
|---|---|---|
| Principal | The actor whose authority is being used. | A user, organization, account, or system that delegates authority. |
| Delegate | The actor that performs work on the principal's behalf. | An AI agent, service, workflow, or human operator acting under a mandate. |
| Mandate | The bounded permission to act. | A structured record containing scope, constraints, lifecycle state, and proof material. |
| Verifier | The actor that checks whether an action is allowed. | A Mandaitor verification surface, API gateway, tool server, or relying integration. |
| Evidence | The record that explains the decision. | Proof-of-Mandate, audit events, runtime traces, and evidence packs. |
Why authentication is not enough
Authentication answers who a caller claims to be and whether that claim can be accepted. Authorization answers what the caller may do. Delegation adds another layer: why may this caller act for someone else, and where are the limits? OAuth 2.0, for example, is an authorization framework that enables third-party applications to obtain limited access to HTTP services, often by separating the resource owner, client, authorization server, and resource server.1 That model is foundational, but agentic systems create a further problem: the action may be planned dynamically after a high-level user instruction, and the specific tool call may need a more contextual authority decision.
| Question | Traditional access-control answer | Why agentic systems need more |
|---|---|---|
| Who is calling? | A session, API key, service account, or token identifies the caller. | The caller may be an agent acting for a user or organization, not merely for itself. |
| What endpoint is reachable? | Roles, scopes, or permissions define accessible resources. | Endpoint access may be broader than the user's actual instruction or mandate. |
| Why is this action allowed now? | The reason is often implicit in account configuration. | The reason must be reconstructed from mandate, context, constraints, and approval. |
| Can this be audited later? | Logs show a request happened. | Evidence must show whether the action was inside delegated authority. |
Mandaitor does not replace identity providers, OAuth flows, or existing access-control layers. It adds an authority layer that asks whether the proposed action belongs inside a verifiable delegation boundary.
Authority boundaries
A mandate boundary is the line between what the delegate may do and what it must not do. A useful boundary is not just a yes/no label. It should express scope, resources, limits, time, parties, context, and lifecycle state. This matters because a delegated agent may encounter many possible actions while pursuing one goal.
| Boundary dimension | Example | What the verifier checks |
|---|---|---|
| Action | Create invoice, read project file, schedule appointment. | Whether the requested operation is listed or implied by policy. |
| Resource | Customer account, building project, contract folder, payment method. | Whether the target resource matches the mandate. |
| Constraint | Amount cap, jurisdiction, data category, business hours, human approval. | Whether the runtime context satisfies the rule. |
| Time | Valid from Monday to Friday, expires after one transaction. | Whether the mandate is current and not expired. |
| Lifecycle | Active, suspended, revoked, superseded. | Whether the mandate may still be used. |
The loop above is the practical Mandaitor operating model. Delegation creates the boundary. Verification checks a concrete action against that boundary. Runtime evidence records the decision. Governance review uses the evidence to improve policies, detect drift, and support accountability.
How a mandate becomes runtime assurance
Read the loop as a sequence of learner questions. A beginner should be able to explain each step without knowing the implementation details of cryptography, DID methods, or API gateways.
A principal creates bounded authority
The principal defines who may act, what action is permitted, which resource is affected, and which constraints limit the action.
- The boundary should be narrower than a broad application role.
- The mandate should be understandable by both systems and reviewers.
A delegate requests a concrete action
The delegate does not rely on capability alone. It presents identity, action, resource, and context so the request can be evaluated before execution.
- The verifier needs facts, not just a generic token.
- Context can include amount, tenant, time, project, or data category.
A verifier checks the mandate boundary
The verifier compares the proposed action with the mandate scope, constraints, lifecycle state, and trust requirements.
- Allowed decisions should be explainable.
- Denied or escalated decisions should produce useful reason codes.
Evidence supports governance review
The result becomes reviewable evidence so teams can improve policies, detect drift, and explain why an agentic action was accepted or rejected.
- Evidence turns runtime decisions into organizational learning.
- Dashboards should point reviewers back to proof, not hide it behind a score.
From informal delegation to verifiable delegation
Human organizations have always delegated authority. A procurement manager may approve purchases below a threshold. A lawyer may act under a power of attorney. A building inspector may validate a specific class of work. The digital challenge is that software systems need a structured representation of these boundaries, and AI agents need that representation at runtime rather than after the fact.
Mandaitor treats delegated authority as a first-class object. Instead of relying on a hidden assumption inside a prompt, workflow, or account role, a mandate records who delegated authority, who may use it, what may be done, under which constraints, and how the decision can be verified later. This turns authorization into a repeatable learning object: teams can inspect the boundary, test edge cases, and improve policy design.
The basic Mandaitor authority lifecycle
The authority lifecycle begins before any action occurs. A principal or authorized system creates a mandate. A delegate later asks to perform a concrete action. A verifier evaluates the action against the mandate and returns a decision. The decision is preserved as evidence so that a reviewer can understand not only what happened, but why it was accepted or rejected.
What this chapter prepares you for
The remaining Academy chapters deepen each part of the lifecycle. Decentralized identity explains how principals and delegates can be represented. Verifiable credentials explain how claims and proofs can travel across systems. Trust-chain chapters explain how verifiers decide whether evidence should be accepted. Policy chapters explain how scope and constraints become enforcement. Agentic AI chapters explain why runtime tool calls change the authorization problem. Evidence and dashboard chapters explain how decisions become reviewable governance artifacts.
| If you want to understand | Read next |
|---|---|
| How agent and principal identities can be represented beyond usernames. | Decentralized Identity and DIDs |
| How Mandaitor's Proof-of-Mandate relates to credential-style evidence. | Verifiable Credentials |
| How boundaries are expressed as policies. | Mandate Policies |
| Why AI tool calls require runtime authorization. | Agentic AI from First Principles |
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.