Agentic Authorization and Runtime Evidence
Agentic Authorization and Runtime Evidence
- Understand agentic AI basics and mandate policy checks.
- connect tool calls to mandate verification at runtime
- explain why authorization must bind actor, action, resource, and context
- describe how allow, deny, and escalate decisions 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. It asks whether the proposed tool call is covered by a valid mandate, whether the mandate's constraints are satisfied, and whether the result should be recorded as 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 by answering the authority question before a sensitive tool call proceeds.
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 | A verifier evaluates whether the action is inside a mandate. | Mandaitor returns allow, deny, or reasoned status. |
| Evidence | The decision and context are recorded. | Reviewers can later reconstruct why the action was allowed or stopped. |
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 can be placed beside MCP hosts, clients, gateways, or tool servers to verify delegated authority before the tool executes.
| 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 verifier | The authority check against mandates and constraints. | The domain-specific execution semantics of every downstream tool. |
| Evidence store | Decision traceability and review support. | 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. |
Design pattern: verify before irreversible action
The safest point to use Mandaitor is before an irreversible or high-impact tool call. 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 verification and evidence policies.
| Tool action class | Example | Recommended Mandaitor pattern |
|---|---|---|
| Low-impact read | Read public documentation or retrieve a non-sensitive status. | Lightweight policy or no Proof-of-Mandate requirement. |
| Sensitive read | Access customer file, financial data, or personal data. | Verify data category, purpose, and user mandate. |
| Reversible write | Draft record, create pending task, stage a proposal. | Verify scope and record evidence; allow human correction. |
| Irreversible or external write | Send payment, submit filing, publish message, update contract. | Verify mandate, require stronger constraints, preserve proof and evidence pack. |
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.
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.