16-scope API key system with per-request authorization decisions. Every agent action verified against trust, sandbox, and policy.
Assign exactly the capabilities each agent needs. No more, no less.
Most agent platforms give you a binary choice: full access or no access. DAT provides 16 granular API key scopes that map directly to business capabilities. A customer-facing chatbot gets TRUST_READ and AGENTS_READ. An internal automation agent gets AGENTS_WRITE and DID_WRITE. Your security team defines the boundaries; the platform enforces them on every single request.
API Key Scope Architecture
==============================
Key Creation:
plaintext = "dat_sk_abc123..."
stored = SHA-256(plaintext)
scopes = ["AGENTS_READ",
"TRUST_READ",
"DID_READ"]
Per-Request Validation:
1. Extract key from header
2. SHA-256 hash
3. Redis lookup (cache hit <1ms)
4. Check scope against route
5. Allow or 403
16 Available Scopes:
AGENTS_READ AGENTS_WRITE
AGENTS_DELETE DID_READ
DID_WRITE TRUST_READ
TRUST_WRITE VERIFY_READ
VERIFY_WRITE WEBHOOKS_READ
WEBHOOKS_WRITE BRIDGE_READ
BRIDGE_WRITE ADMIN_READ
ADMIN_WRITE MONITORING_READ
Example: Chatbot API Key
Scopes: AGENTS_READ, TRUST_READ
Cannot: register agents, write
trust signals, manage DIDsTrust scores, sandbox levels, and policy engines converge on a single decision point for every tool call.
When an agent tries to execute a tool — send an email, scrape a webpage, delegate to another agent — the request passes through DAT's Trust Gate. This is not a static ACL check. The gate re-fetches the agent's live trust score on every iteration, maps it to a sandbox level, evaluates tool risk ratings, and optionally routes to human-in-the-loop approval. If trust drops mid-task, capabilities shrink immediately.
Per-Request Authorization Flow
==============================
Agent wants to: send_email(to, body)
Step 1: Fetch live trust score
GET /reputation/{agentDid}
-> trustScore: 72.5
Step 2: Map to sandbox level
0-30 -> STRICT (3 tools)
30-70 -> ADAPTIVE (15 tools)
70-100 -> OPEN (40 tools)
-> OPEN
Step 3: Check tool risk
send_email:
risk: "high"
minSandbox: OPEN
requiresApproval: true
-> Allowed (OPEN >= OPEN)
Step 4: HITL approval required
-> Send approval to Teams/Slack
-> Wait for human response
-> "Approved by security role"
Step 5: Execute tool
-> Email sent via SMTP
Step 6: Report signal
-> action_success
-> Trust: 72.5 -> 72.8
If trust drops to 65 mid-task:
-> Sandbox: ADAPTIVE
-> send_email: DENIED (need OPEN)
-> Agent loses email capabilityHigh-stakes agent actions require sign-off from the right people, not just any person.
A single "approve" button is not enough for enterprise-grade agent governance. DAT's multi-sig threshold approval system lets you define how many approvals each tool needs and which organizational roles must be represented. An email send might need one approval from any role. A skill builder deployment might need two approvals, one from security and one from engineering. Veto power means any single rejection blocks the action.
Multi-Sig Approval Policy
==============================
Tool: build_skill
requiredApprovals: 2
requiredRoles: ["security",
"engineering"]
Approval Flow:
1. Agent requests build_skill
2. Trust Gate creates approval
3. Notifications sent to:
- Teams (Adaptive Card)
- Slack (Block Kit)
- Telegram (Inline keyboard)
- Dashboard (Approvals page)
4. Vote 1: security -> Approve
Progress: [*][_] (1/2)
5. Vote 2: engineering -> Approve
Progress: [*][*] (2/2)
6. Resolution: APPROVED
Both count AND roles satisfied
Veto Example:
Vote 1: security -> Approve
Vote 2: compliance -> Reject
-> REJECTED (any rejection = veto)
Admin Override:
Service-to-service callers
(Telegram/Slack/Teams bots)
-> single vote resolves allDeploy agents with granular permissions that adapt to behavior. Start with a free account and define your first scoped API key.