Skip to main content
MAIP policies let you enforce guardrails on AI agent behavior at runtime. When an agent requests access to a scoped resource, all active policies are evaluated before the action proceeds. If any policy denies the request, the action is blocked.
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., llm or worker) from accessing certain scopes
  • Enforce different rules for different risk levels without changing agent code
  • Add runtime guardrails to multi-agent orchestration workflows
If you don’t create any MAIP policies, agent access is controlled only by scope assignments and agent status.

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
  • Effectallow, deny, or require_approval
  • requires_approval — optional flag that triggers a human approval workflow
Rules within a policy are evaluated independently. If any rule with a deny effect matches, the action is blocked regardless of any allow rules. This is a deny-overrides model.
Agent requests scope → Evaluate all active policies (priority order)

                     ┌────────┼────────┐
                     ▼        ▼        ▼
                  Policy A  Policy B  Policy C
                  (p: 10)   (p: 20)  (p: 100)
                     │        │        │
                     ▼        ▼        ▼
               Any deny? ──yes──→ Action BLOCKED

                  no


             Action ALLOWED

Evaluation order

  1. Agent status — the agent must be active. Suspended or revoked agents are always denied.
  2. Scope check — the requested scope must be in the agent’s granted scopes. Explicitly denied scopes (prefixed with !) always block access.
  3. Policy rules — all active tenant policies are evaluated in priority order (lower numbers first). Each rule’s conditions are AND-ed.

Condition fields

FieldTypeOperatorsDescription
trust_scorenumberlt, gt, le, geAgent’s current trust score (0.0–1.0)
scopestringeq, ne, in, containsThe scope being requested (e.g., data:write)
agent_typestringeq, ne, inAgent type (e.g., llm, worker, orchestrator)
delegation_depthnumbergt, ge, lt, lePosition in the delegation chain (0 = direct)

Operators

OperatorDescriptionExample value
eqEquals"data:write"
neNot equals"system"
ltLess than0.5
gtGreater than3
leLess than or equal0.3
geGreater than or equal0.7
inMatches any value in a list["llm", "worker"]
containsString contains substring"write"

Effects

EffectBehavior
allowExplicitly allow the action. Does not override denials from other rules.
denyBlock the action. First deny wins.
require_approvalAllow the action but flag it for human approval before proceeding.

Creating a policy

curl -X POST https://api.truthlocks.com/v1/maip/policies \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Block Low-Trust Write Operations",
    "description": "Deny data:write scope for agents with trust score below 0.5",
    "category": "trust",
    "priority": 10,
    "rules": [
      {
        "conditions": [
          {"field": "trust_score", "op": "lt", "value": 0.5},
          {"field": "scope", "op": "eq", "value": "data:write"}
        ],
        "effect": "deny",
        "requires_approval": false
      }
    ]
  }'
All new policies are created with status: "active" and take effect immediately.

Policy categories

CategoryUse case
scopeRestrict access based on specific scopes or resources
trustRestrict access based on trust score thresholds
rateRestrict access frequency or volume
customCustom enforcement logic (default if omitted)

Priority

The priority 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.
curl -X POST https://api.truthlocks.com/v1/maip/policies/evaluate \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "maip:t1234567:01HYX3KPZQ7RJGBN0WFMV8SDEH",
    "scope": "data:write",
    "action": "update_customer_record",
    "resource": "customers/cust_12345"
  }'
Allowed response:
{
  "allowed": true,
  "requires_approval": false
}
Denied response:
{
  "allowed": false,
  "denied_by": ["Block Low-Trust Write Operations"],
  "reason": "denied by policy",
  "requires_approval": false
}
Requires approval response:
{
  "allowed": true,
  "requires_approval": true
}
When requires_approval is true, your application should route the action through a human approval workflow before proceeding.

Listing policies

curl https://api.truthlocks.com/v1/maip/policies \
  -H "X-API-Key: $API_KEY"
Returns all MAIP policies for your tenant, including their rules, priority, and status.

Common patterns

Block untrusted agents from writing data

Deny any agent with a trust score below 0.5 from accessing write scopes.
{
  "name": "Block Low-Trust Writes",
  "category": "trust",
  "priority": 10,
  "rules": [
    {
      "conditions": [
        { "field": "trust_score", "op": "lt", "value": 0.5 },
        { "field": "scope", "op": "eq", "value": "data:write" }
      ],
      "effect": "deny"
    }
  ]
}

Require approval for deep delegation chains

Agents more than three levels deep in a delegation chain must get human approval for any action.
{
  "name": "Approval for Deep Delegation",
  "category": "scope",
  "priority": 20,
  "rules": [
    {
      "conditions": [
        { "field": "delegation_depth", "op": "gt", "value": 3 }
      ],
      "effect": "require_approval",
      "requires_approval": true
    }
  ]
}

Restrict LLM agents from executing tools

Prevent LLM-type agents from invoking tool execution scopes while allowing other agent types.
{
  "name": "No Tool Execution for LLMs",
  "category": "scope",
  "priority": 15,
  "rules": [
    {
      "conditions": [
        { "field": "agent_type", "op": "eq", "value": "llm" },
        { "field": "scope", "op": "eq", "value": "tool:execute" }
      ],
      "effect": "deny"
    }
  ]
}

Block multiple agent types from a scope

Use the in operator to match against a list of values instead of writing separate rules for each agent type.
{
  "name": "No Autonomous Writes",
  "category": "scope",
  "priority": 10,
  "rules": [
    {
      "conditions": [
        { "field": "agent_type", "op": "in", "value": ["llm", "worker"] },
        { "field": "scope", "op": "eq", "value": "data:write" }
      ],
      "effect": "deny"
    }
  ]
}

Deny all write scopes with a single rule

Use the contains operator to match any scope that includes a substring, rather than listing each write scope individually.
{
  "name": "Read-Only for Low Trust",
  "category": "trust",
  "priority": 10,
  "rules": [
    {
      "conditions": [
        { "field": "trust_score", "op": "lt", "value": 0.5 },
        { "field": "scope", "op": "contains", "value": "write" }
      ],
      "effect": "deny"
    }
  ]
}

Combine multiple rules in one policy

A single policy can contain multiple rules for layered enforcement:
{
  "name": "Production Safety Net",
  "category": "custom",
  "priority": 5,
  "rules": [
    {
      "conditions": [
        { "field": "trust_score", "op": "lt", "value": 0.3 }
      ],
      "effect": "deny"
    },
    {
      "conditions": [
        { "field": "trust_score", "op": "lt", "value": 0.7 },
        { "field": "scope", "op": "eq", "value": "data:write" }
      ],
      "effect": "require_approval",
      "requires_approval": true
    }
  ]
}
This policy blocks agents with trust scores below 0.3 outright, and requires human approval for write operations from agents scoring between 0.3 and 0.7.

MAIP policies vs. RBAC policies

MAIP policiesRBAC (issuance) policies
GovernsMachine agent runtime behaviorCredential minting, verification, and export
SubjectsAI agents identified by MAIP IDHuman users and issuers
Condition fieldstrust_score, scope, agent_type, delegation_depthjurisdiction, trust_tier, risk_rating, key.age_days
Evaluation modelDeny-overrides (any deny blocks)First-match wins
API path/v1/maip/policies/v1/policies

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.