Architecture & Mental Model
Dmint is built on a simple premise: AI agents propose actions, but code and deterministic policy authorize them. To understand how Dmint secures tool execution, here are the four core primitives:The Four Primitives
1. Capabilities
A capability identifies an actionable operation in the formattool.action:
database.selectfilesystem.read_filebash.execute_command
*).
2. Exact Request Binding
Unlike human RBAC (which grants broad permissions like “user may update rows”), Dmint approvals authorize one exact request payload:- The tool name (
postgres) - The action (
update) - The sorted, type-preserved arguments (
{"table": "users", "id": 42}) - The deployment epoch
3. Declarative Policies
Policies are defined inpolicy.json. Every rule has:
effect:allow,deny, orapproval_requiredtool: the target tool namespaceaction: the target action nameresource: a specific resource string, glob pattern, or*
4. Single-Use Approval State Machine
When an operation triggersAPPROVAL_REQUIRED:
PENDING: Request is saved into SQLite with its canonical fingerprint and parameter snapshot.APPROVED: A human approver inspects the payload and signs an assertion using Ed25519.CONSUMED: The agent retries the call. Dmint validates the signature against the active policy, checks that the fingerprint matches, and atomically transitions the record toCONSUMED.
Core vs Gateways vs Dashboard
Dmint divides responsibilities strictly to avoid privilege escalation:Next Steps
Capabilities
Learn how tools, actions, and resources are structured.
Request Binding
Understand RFC 8785 canonicalization and fingerprinting.
Approvals Lifecycle
Explore how human approval tokens are signed and consumed.
Policies
Deep-dive into policy schema and rule evaluation order.