When agents call other agents autonomously, you need to control who can call what. An internal analytics agent shouldn't be able to invoke a payment processing agent. A third-party plugin shouldn't access your customer data agent.

Agentfield's permissions system uses tag-based access policies with DID-authenticated requests to enforce fine-grained access control between agents. Admins define policies, agents authenticate with cryptographic signatures, and the control plane enforces rules at execution time.

Two-Step Authorization Model

Agentfield's authorization works in two steps:

How It Works

1. Agent Registration with Tags

Agents declare their proposed tags when registering with the control plane:

from agentfield import Agent

app = Agent(
    node_id="payment-processor",
    tags=["finance", "pci-compliant", "internal"],
    description="Handles payment processing"
)

const agent = new Agent({
  nodeId: 'payment-processor',
  tags: ['finance', 'pci-compliant', 'internal'],
  description: 'Handles payment processing'
});

agentNode, _ := agent.New(agent.Config{
    NodeID: "payment-processor",
    Tags:   []string{"finance", "pci-compliant", "internal"},
})

When tag approval mode is admin, the agent enters a pending_approval state until an admin approves the tags.

2. Admin Defines Access Policies

Policies are ALLOW or DENY rules that match tags:

# agentfield.yaml
authorization:
  enabled: true
  tag_approval_mode: admin  # "auto" or "admin"
  access_policies:
    - effect: ALLOW
      caller_tags: ["internal"]
      target_tags: ["finance"]
      description: "Internal agents can access finance services"

    - effect: DENY
      caller_tags: ["third-party"]
      target_tags: ["pci-compliant"]
      description: "Third-party agents cannot access PCI systems"

    - effect: ALLOW
      caller_tags: ["analytics"]
      target_tags: ["data"]
      actions: ["*.read_*", "*.get_*"]
      description: "Analytics agents can only read data"

Policies are evaluated in priority order. The first matching policy wins. If no policy matches, the request is allowed by default (zero-disruption mode).

3. DID-Authenticated Requests

When Agent A calls Agent B, the SDK automatically signs the request using the agent's DID (Decentralized Identifier) keypair:

POST /api/v1/execute/payment-processor.charge
X-Caller-DID: did:web:example.com:agents:analytics-agent
X-DID-Signature: <Ed25519 signature>
X-DID-Timestamp: 1709000000
X-DID-Nonce: abc123

The signature covers {timestamp}:{nonce}:{SHA256(body)}, providing cryptographic proof of the caller's identity.

4. Control Plane Enforces Policies

When the request arrives at the control plane:

1. DID Auth Middleware verifies the Ed25519 signature against the caller's DID document public key
2. Permission Middleware resolves the caller's tags, evaluates access policies, and checks for an existing PermissionApproval
3. If denied, the system auto-creates a PermissionRequest for admin review

Admin UI

The Authorization page in the Agentfield UI provides:

• Access Rules Tab — View, create, and delete ALLOW/DENY policies with color-coded indicators
• Agent Tags Tab — See all agents with their proposed and approved tags, approve or reject tag requests
• Approval Dialogs — Approve tags with a preview of which policies will apply
• Revocation — Revoke previously approved permissions at any time

Agent-to-Agent Direct Verification

For latency-sensitive workloads, agents can verify requests locally without round-tripping to the control plane. Each SDK includes a LocalVerifier that caches:

• Access policies
• Revocation lists
• Registered DIDs
• Admin public key

from agentfield import Agent

app = Agent(
    node_id="payment-processor",
    tags=["finance"],
    # Local verification is enabled automatically
    # when authorization is configured
)

# The agent's middleware verifies incoming DID signatures
# and evaluates policies locally using cached data

agentNode, _ := agent.New(agent.Config{
    NodeID: "payment-processor",
    Tags:   []string{"finance"},
    // LocalVerifier caches policies, revocation lists,
    // and registered DIDs from the control plane
})

The LocalVerifier periodically refreshes its cache from the control plane, so policy changes propagate automatically.

Configuration

Environment Variables

YAML Configuration

authorization:
  enabled: true
  master_seed: "your-secure-seed-here"
  tag_approval_mode: admin
  access_policies:
    - effect: ALLOW
      caller_tags: ["internal"]
      target_tags: ["*"]
      description: "Internal agents have full access"

Permission Request Flow

When an agent is denied access:

1. The control plane automatically creates a PermissionRequest
2. The request appears in the admin UI under pending permissions
3. Admin approves or rejects with optional context
4. Approved agents can retry the call immediately
5. Admins can revoke approvals at any time, and the system handles re-requests

API Reference

Permission Endpoints

Tag Management Endpoints

Access Policy Endpoints

Next Steps

• Human-in-the-Loop — Pause agents for human approval on high-stakes decisions
• Identity & DIDs — How DID identities are generated and managed
• Verifiable Credentials — Cryptographic proof of agent actions
• Authentication — API key authentication for the control plane