Mandate Policies and Policy Enforcement
Mandate Policies and Policy Enforcement
- Understand mandates as bounded authority objects and know the basic verification model.
- translate delegated authority into action, resource, constraint, and lifecycle rules
- understand why policies must be checked at runtime
- recognize common policy failure modes before production rollout
A mandate policy is the structured boundary that decides what a delegate may do. It turns an informal instruction into something a verifier can evaluate. A useful policy does not merely say “Agent A is allowed.” It describes the action, resource, constraints, time window, obligations, lifecycle status, and expected evidence.
Mandaitor policies should be understandable to humans and precise enough for machines. The best policy is narrow where risk is high, flexible where work genuinely varies, and explicit about what happens when the verifier cannot decide.
The anatomy of a mandate policy
| Policy element | Plain-language meaning | Example |
|---|---|---|
| Principal | The authority owner. | Organization, user, project owner, account holder. |
| Delegate | The actor allowed to act. | Named agent, workflow, service, or employee role. |
| Action | What may be done. | Read, create, approve, submit, pay, notify. |
| Resource | What the action affects. | Project, invoice, customer record, file, contract. |
| Constraint | A condition that must be true. | Amount below threshold, before expiry, within jurisdiction. |
| Obligation | A required follow-up or side effect. | Notify reviewer, attach evidence, request dual approval. |
| Lifecycle | Whether the mandate can currently be used. | Active, suspended, expired, revoked, superseded. |
Allow, deny, and require approval
Not every decision is a simple allow or deny. Some actions should be allowed automatically, some denied automatically, and some routed to approval. This is especially important for agentic AI because the agent may propose an action that is close to a boundary but requires human judgment.
| Decision | Meaning | Example response |
|---|---|---|
| Allow | The action fits the mandate and constraints. | Execute and record proof. |
| Deny | The action is outside authority or violates a hard rule. | Stop and explain reason. |
| Require approval | The action may be possible but needs human review. | Ask principal or approver. |
| Require more context | The verifier cannot evaluate a constraint yet. | Provide amount, purpose, resource, or classification. |
Constraints make authority safe enough to use
Constraints prevent a mandate from becoming a broad permission token. They reduce risk by narrowing when, where, how, and under which conditions authority can be used. A constraint should be explicit enough that a system can evaluate it or route it to the correct reviewer.
| Constraint type | Example | What it protects against |
|---|---|---|
| Time | Valid only until Friday or for one session. | Stale authority and forgotten approvals. |
| Amount | Payments below EUR 5,000. | Unexpected financial exposure. |
| Resource | Only project Alpha or customer account 123. | Cross-resource overreach. |
| Purpose | Only for onboarding or invoice reconciliation. | Secondary use outside original intent. |
| Location or jurisdiction | Only within an approved region. | Regulatory or contractual mismatch. |
| Human approval | Require review for high-risk actions. | Fully automated irreversible harm. |
| Rate | Maximum number of actions per period. | Abuse, runaway loops, or automation errors. |
Policy enforcement pipeline
Mandaitor policy enforcement can be explained as a pipeline. The verifier receives an action request, resolves actor and mandate context, evaluates the policy, checks lifecycle and status, returns a decision, and emits evidence.
| Pipeline step | Failure mode | Good design response |
|---|---|---|
| Resolve actor | Unknown or mismatched delegate. | Require agent registration and identity binding. |
| Resolve mandate | No mandate or wrong mandate. | Deny with clear reason or request proper delegation. |
| Evaluate action | Action name too broad or ambiguous. | Use action taxonomy and examples. |
| Evaluate resource | Resource identifier missing or too general. | Require structured resource context. |
| Evaluate constraints | Missing amount, expiry, or purpose. | Return “needs context” rather than guessing. |
| Emit evidence | Decision not recorded. | Treat evidence requirements as part of policy. |
Policy design examples
| Scenario | Weak policy | Stronger mandate policy |
|---|---|---|
| Finance agent | Agent may manage payments. | Agent may create payment drafts below EUR 5,000 for approved vendors until quarter end; submission requires human approval. |
| Document agent | Agent may access files. | Agent may read project Alpha documents excluding restricted HR and legal folders for the purpose of validation. |
| Support agent | Agent may update customer records. | Agent may update non-sensitive support fields for assigned customers during active tickets. |
| Procurement agent | Agent may buy supplies. | Agent may request quotes for approved categories and place orders below a defined threshold after budget validation. |
Practice check: write a safer mandate policy
Policy boundary design
A procurement team wants an AI delegate to negotiate with approved suppliers, create purchase-order drafts, and submit orders below EUR 2,000. Anything above the threshold, anything involving a new supplier, or anything changing payment terms must require human approval.
This exercise should produce a policy sketch, not legal prose. A useful Mandaitor policy is precise enough for software to enforce and plain enough for humans to review.
- Separate allowed and escalated actionsWrite the actions that can proceed automatically and the actions that must move to approval.
- Define constraintsName the amount, supplier, time, role, and resource constraints that make the mandate testable.
- Add evidence requirementsSpecify which proof, reason, and approval fields should be recorded when the verifier returns allow or escalate.
- Least authority
- The policy grants only the authority needed for the procurement workflow.
- Machine testability
- The constraints can be evaluated at runtime without relying on vague intent.
- Reviewer usefulness
- The evidence fields explain why a purchase-order draft was allowed or escalated.
Which policy design is safest for the procurement delegate?
- Allow all procurement activity because the delegate belongs to the finance workspace.
- Allow approved-supplier drafts and orders below EUR 2,000, while escalating new suppliers, payment-term changes, and higher amounts.
- Deny all writes and allow only public reads, regardless of the team's workflow needs.
Reveal answer
The second option best reflects bounded delegation. It allows the useful low-risk workflow while preserving explicit escalation points for higher-risk supplier, amount, and payment-term changes.
What to read next
Read Agentic AI from First Principles to understand why policies must be checked at runtime. Read Agentic Authorization and Runtime Evidence to see the runtime pipeline in action. Read Compliance Dashboard Explained to understand how policy outcomes appear in review surfaces.
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.