Agentic Authorization and Runtime Evidence
Agentic Authorization and Runtime Evidence
- Understand agentic AI basics and mandate policy checks.
- connect tool calls to mandate decisions at runtime
- explain why authorization must bind actor, action, the record's facts, and context
- describe how allowed, denied and approval-bound requests become evidence
Agentic authorization is the discipline of deciding whether an AI agent may perform a concrete action at the moment the action is about to happen. The decision cannot be made only when the user starts a chat, and it cannot rely only on a broad API token. A modern agent may plan steps, choose tools, read context, call external systems, and adapt its behavior while pursuing a goal. That makes authorization a runtime control problem.
Mandaitor sits in the action path, and in its execution model it is the action path. The agent asks Mandaitor to perform the tool call. Mandaitor decides whether a valid mandate covers it and whether the mandate's constraints hold on the record as the target system holds it. It performs the call only then, and records the evidence. This is especially important when the tool action can spend money, change records, submit information, access sensitive data, or trigger a business workflow.
The Model Context Protocol specification defines MCP as an open protocol that connects LLM applications with external data sources and tools, with hosts, clients, and servers communicating through JSON-RPC 2.0 messages.1 MCP standardizes how agentic applications expose and use tools. Mandaitor complements that layer: it is itself an MCP server, which decides each business tool call against the agent's mandates and carries it out.
From chat to tool action
A chatbot that only drafts text creates one kind of risk. An agent that can call tools creates another. The risk appears when a high-level instruction becomes a concrete external action. A user might say, “prepare the supplier payment,” but the agent might need to read invoices, choose a bank account, create a payment request, notify approvers, and update an ERP system. Each step has a different authority boundary.
| Stage | Beginner explanation | Mandaitor concern |
|---|---|---|
| User intention | The user states a goal in natural language. | The goal may be broad or ambiguous. |
| Agent plan | The agent decomposes the goal into steps. | Some steps may exceed the intended authority. |
| Tool proposal | The runtime prepares a concrete API or tool call. | This is the best moment to check action, resource, and constraints. |
| Authority check | Mandaitor decides on the facts it read from the record. | Allowed, denied with a reason, or waiting for a person's approval. Only an allowed request is performed. |
| Evidence | The decision, the authorization and the outcome are recorded. | Reviewers can later reconstruct why the action was allowed or stopped, and what it did. |
MCP and Mandaitor are complementary
MCP describes a communication pattern for tools and context. It does not by itself determine whether every possible tool call is appropriate for a specific user, mandate, risk class, or business situation. Mandaitor's answer is to be the MCP server for business operations: the agent's MCP client calls Mandaitor, which decides each call against the agent's mandates and performs it with a credential the agent never holds.
| Layer | What it standardizes | What it does not automatically solve |
|---|---|---|
| MCP host/client/server | How an LLM application connects to tools and context providers.1 | Whether a specific user or delegate has authority for a concrete action. |
| Tool server | The available operations and schemas. | Whether a dynamically chosen operation is appropriate in the current mandate. |
| Mandaitor | The decision against mandates on the record's facts, and the write itself: one reviewed tool per operation. | Operations it has no tool for, which it cannot be asked to perform. |
| Audit trail | Decision traceability, Proofs-of-Mandate and receipts. | Business judgment about whether policy should later be changed. |
Consent, authorization, and evidence are different
User consent is necessary, but it is not the whole authorization model. A user may consent to an agent's general goal without reviewing every low-level tool call. A policy may allow a tool call only below a threshold. A compliance reviewer may need evidence days or months later. These needs overlap but are not identical.
| Concept | What it answers | Example |
|---|---|---|
| Consent | Did a human or principal approve a delegation or interaction? | A user approves that an agent may prepare invoices this week. |
| Authorization | Is this concrete action allowed under policy and mandate? | The agent may create invoices below EUR 5,000 for one customer. |
| Authentication | Who is the actor or system making the request? | The caller is Agent A using a registered identity. |
| Evidence | Can the decision be inspected later? | An audit event shows the action, resource, mandate, and reason code. |
Mandaitor's role is to connect these concepts. It allows a system to represent consent and mandate boundaries, enforce authorization at runtime, bind the action to identities, and preserve evidence for review.
Runtime evidence as a safety mechanism
Runtime evidence is more than logging. Logs often answer “what request occurred?” Evidence should also answer “what authority was checked, what policy applied, and why was the result accepted or rejected?” This changes how teams investigate incidents, satisfy counterparties, and operate agentic workflows.
| Evidence field | Why it is useful |
|---|---|
| Mandate identifier | Connects the action to the delegated authority boundary. |
| Principal and delegate | Shows who delegated and who acted. |
| Action and resource | Prevents a broad “authorized” label from hiding what was attempted. |
| Constraint evaluation | Shows which limits were checked. |
| Decision reason | Helps developers, users, and reviewers understand outcomes. |
| Timestamp and status | Supports freshness, expiry, incident response, and chronology. |
| Outcome and record versions | Shows what the write did, as read back from the system: the receipt. |
Design pattern: let Mandaitor perform irreversible actions
The most important place for Mandaitor is an irreversible or high-impact tool call. There, the agent should not hold the credential at all: Mandaitor should perform the call, on the record as it reads it. That does not mean every low-risk read must always trigger heavy review. It means that tool calls should be classified by impact and routed through appropriate decision and evidence policies.
| Tool action class | Example | Recommended Mandaitor pattern |
|---|---|---|
| Low-impact read | Read public documentation or retrieve a non-sensitive status. | Lightweight policy, no approval. |
| Sensitive read | Access customer file, financial data, or personal data. | A mandate that names the data category and the purpose. |
| Reversible write | Draft record, create pending task, stage a proposal. | A mandate with limits, evidence kept, and room for human correction. |
| Irreversible or external write | Send payment, submit filing, publish message, update contract. | Mandaitor performs it: limits, an approval threshold, a Proof-of-Mandate and a receipt. |
Practice check: authorize the next tool call
Runtime authorization triage
An agent has been asked to prepare supplier payments for the finance team. It now proposes a tool call that creates a payment instruction for EUR 7,500, even though the current mandate allows invoice preparation and payment drafts below EUR 5,000.
Treat this as a reviewer drill. The goal is not to make the agent stop forever; the goal is to keep the next irreversible action inside a verifiable authority boundary.
- Classify the proposed actionDecide whether the tool call is a low-impact read, sensitive read, reversible write, or irreversible external write.
- Name the missing authorityIdentify which part of actor, action, resource, amount, timing, or approval context prevents immediate execution.
- Choose the runtime outcomeReturn allow, deny, or escalate, and write the reason code that should be preserved in evidence.
- Specificity
- The answer evaluates the concrete payment instruction rather than the user's broad goal.
- Boundary awareness
- The answer notices that the amount exceeds the mandate and that payment execution is higher impact than preparation.
- Evidence quality
- The answer records a decision, reason, mandate reference, actor, resource, and escalation path.
Why is the proposed EUR 7,500 payment instruction not automatically allowed even if the user asked the agent to prepare supplier payments?
- Because broad user intent does not replace the mandate's concrete amount, action, and approval constraints.
- Because any payment-related task must always be blocked, even drafts.
- Because MCP tools cannot be used with authorization checks.
Reveal answer
The user's instruction is relevant context, but the runtime decision must still verify the concrete tool call against the mandate. In this case the amount exceeds the threshold and the action may move from preparation into external payment execution, so the safe result is denial or escalation with preserved evidence.
Play: Scope Trial — you are the verifier
Eight rounds, one mandate and one incoming request each. Call ALLOW, DENY, or REVIEW before the verifier reveals its decision — the game runs the same evaluation logic as the public sandbox. Six or more correct marks this lesson complete.
A procurement agent files a purchase order inside its project.
- Delegate
construction:agent:procure-v1- Allowed actions
procurement.order.create- Resource scope
construction:project:proj_771/*- Status
- ACTIVE
- Action
procurement.order.create- Resource
construction:project:proj_771/po:2201
What to read next
Read Evidence Packs and Audit Events to understand how runtime decisions become reviewable artifacts. Read Mandate Policies if you want to design the policy boundaries that this chapter enforces. Read Compliance Dashboard Explained if you want to understand how runtime evidence becomes visible to leadership and reviewers.
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.