MAIP policies are different from issuance policies. Issuance policies govern credential minting and verification for human users and issuers. MAIP policies govern machine agent behavior at runtime — controlling what agents can do based on trust scores, delegation depth, scopes, and agent type.
When to use MAIP policies
Use MAIP policies when you need to:- Block agents with low trust scores from performing sensitive operations
- Require human approval when an agent is deep in a delegation chain
- Restrict specific agent types (e.g.,
llmorworker) from accessing certain scopes - Enforce different rules for different risk levels without changing agent code
- Add runtime guardrails to multi-agent orchestration workflows
How policies work
Each MAIP policy contains one or more rules. Each rule has:- Conditions — field-level checks evaluated against the requesting agent’s context
- Effect —
allow,deny, orrequire_approval - requires_approval — optional flag that triggers a human approval workflow
deny effect matches, the action is blocked regardless of any allow rules. This is a deny-overrides model.
Evaluation order
- Agent status — the agent must be
active. Suspended or revoked agents are always denied. - Scope check — the requested scope must be in the agent’s granted scopes. Explicitly denied scopes (prefixed with
!) always block access. - Policy rules — all active tenant policies are evaluated in priority order (lower numbers first). Each rule’s conditions are AND-ed.
Condition fields
| Field | Type | Operators | Description |
|---|---|---|---|
trust_score | number | lt, gt, le, ge | Agent’s current trust score (0.0–1.0) |
scope | string | eq, ne, in, contains | The scope being requested (e.g., data:write) |
agent_type | string | eq, ne, in | Agent type (e.g., llm, worker, orchestrator) |
delegation_depth | number | gt, ge, lt, le | Position in the delegation chain (0 = direct) |
Operators
| Operator | Description | Example value |
|---|---|---|
eq | Equals | "data:write" |
ne | Not equals | "system" |
lt | Less than | 0.5 |
gt | Greater than | 3 |
le | Less than or equal | 0.3 |
ge | Greater than or equal | 0.7 |
in | Matches any value in a list | ["llm", "worker"] |
contains | String contains substring | "write" |
Effects
| Effect | Behavior |
|---|---|
allow | Explicitly allow the action. Does not override denials from other rules. |
deny | Block the action. First deny wins. |
require_approval | Allow the action but flag it for human approval before proceeding. |
Creating a policy
status: "active" and take effect immediately.
Policy categories
| Category | Use case |
|---|---|
scope | Restrict access based on specific scopes or resources |
trust | Restrict access based on trust score thresholds |
rate | Restrict access frequency or volume |
custom | Custom enforcement logic (default if omitted) |
Priority
Thepriority field controls evaluation order. Lower numbers are evaluated first. Range: 1–1000. Default: 100. If multiple policies share the same priority, they are evaluated in creation order.
Evaluating policies at runtime
Call the evaluate endpoint before your agent performs a sensitive operation. The response tells you whether the action is allowed, denied, or requires human approval.requires_approval is true, your application should route the action through a human approval workflow before proceeding.
Listing policies
Common patterns
Block untrusted agents from writing data
Deny any agent with a trust score below 0.5 from accessing write scopes.Require approval for deep delegation chains
Agents more than three levels deep in a delegation chain must get human approval for any action.Restrict LLM agents from executing tools
Prevent LLM-type agents from invoking tool execution scopes while allowing other agent types.Block multiple agent types from a scope
Use thein operator to match against a list of values instead of writing separate rules for each agent type.
Deny all write scopes with a single rule
Use thecontains operator to match any scope that includes a substring, rather than listing each write scope individually.
Combine multiple rules in one policy
A single policy can contain multiple rules for layered enforcement:MAIP policies vs. RBAC policies
| MAIP policies | RBAC (issuance) policies | |
|---|---|---|
| Governs | Machine agent runtime behavior | Credential minting, verification, and export |
| Subjects | AI agents identified by MAIP ID | Human users and issuers |
| Condition fields | trust_score, scope, agent_type, delegation_depth | jurisdiction, trust_tier, risk_rating, key.age_days |
| Evaluation model | Deny-overrides (any deny blocks) | First-match wins |
| API path | /v1/maip/policies | /v1/policies |
Related
MAIP Policies API reference
Create, list, and evaluate MAIP policies via the REST API.
Trust scores
Understand the trust scoring system that feeds into policy conditions.
Agent authorization
Scope-based authorization and session management for agents.
Machine identity
Full overview of the Machine Agent Identity Protocol.

