Home Platform Dynamic Scoping

Trust-Adaptive Sandbox Architecture

Agent capabilities expand and contract based on earned trust. New agents start in a tightly constrained sandbox and unlock more powerful tools as they prove reliable. No manual promotion, no static role assignments.

Three Levels of Autonomy

Agents move fluidly between sandbox tiers as their trust score changes in real time.

Capabilities That Match Trustworthiness

When you deploy a new agent, it should not have the same access as one that has been running reliably for six months. DAT's three-tier sandbox gives every agent precisely the capabilities its track record warrants, and adjusts continuously as behavior changes.

  • STRICT (Trust 0-30) — Filesystem read-only. 3 iterations max. Safe quarantine for unproven agents
  • ADAPTIVE (Trust 30-70) — Shell commands, web search, HTTP, email read, browser. 20 iterations. Production workhorse
  • OPEN (Trust 70-100) — Full toolset including email send, form fill, delegation, skill creation. 25 iterations. Fully trusted

A compromised agent does not keep its privileges. When trust drops, tools are revoked in the same iteration. No restart, no redeployment, no human intervention required.

Sandbox Level Mapping
==============================

STRICT   [Trust 0-30]
  Tools:  read_file
          list_directory
          search_files
  Iters:  3 max
  Use:    New / untrusted agents

ADAPTIVE [Trust 30-70]
  Tools:  + execute_command (ro)
          + web_search
          + fetch_url, http_get
          + read_inbox
          + browse_url, screenshot
          + extract_data
          + recall, remember
          + 20 compound skills
  Iters:  20 max
  Use:    Production workload

OPEN     [Trust 70-100]
  Tools:  + send_email
          + click_element, fill_form
          + delegate_task
          + build_skill
          + http_request (full)
          + 8 more compound skills
  Iters:  25 max
  Use:    Fully autonomous agents

Per-Iteration Re-Evaluation

Trust is not checked once. It is checked before every single tool call.

The Trust Gate: Every Action Authorized

Before an agent can execute any tool, the request passes through a Trust Gate that performs three checks in sequence: Is the agent's trust score high enough for this sandbox level? Does the authorization service approve this specific action? Is the tool's risk level compatible with the current scope?

  • Live Score Fetch — Trust score re-fetched from reputation service every iteration
  • Authorization Check — External authorization service validates the specific action
  • Tool Risk Classification — Low, medium, and high risk tools mapped to minimum sandbox levels
  • Network Fail-Closed — If the auth service is unreachable, network tools are denied
  • HITL Approval — High-risk tools can require human approval before execution

The result is zero-trust agent execution where every capability is earned and verified in real time, not assumed from a config file.

Trust Gate Flow (per tool call)
==============================

1. Agent requests: "send_email"

2. Fetch live trust score
   GET reputation:3006/:did
   -> trust = 72.4

3. Determine sandbox level
   72.4 >= 70 -> OPEN

4. Check tool requirements
   send_email:
     minSandbox: OPEN
     riskLevel:  high
     requiresApproval: true

5. Authorize action
   POST authorization:3003
   -> allowed: true

6. Human approval
   -> Telegram/Slack/Teams
   -> Manager approves

7. Execute tool
   -> Email sent

8. Report trust signal
   POST reputation:3006
   -> action_success

If trust drops to 65 next iteration:
   sandbox -> ADAPTIVE
   send_email -> DENIED (need OPEN)

Beyond Static RBAC

Traditional role-based access was designed for humans. Agents need something better.

Why Static Roles Fail for AI Agents

Role-Based Access Control assigns fixed permissions at deployment time and never revisits them. An agent with the "Power User" role keeps that role even after producing anomalous behavior, failing tasks, or being compromised. You only discover the problem in a post-incident review.

DAT replaces this with dynamic, behavioral scoping. Permissions are not a label attached to an agent; they are a live function of how the agent is performing right now. There is no drift between what an agent is allowed to do and what it should be allowed to do.

Capability Traditional RBAC DAT Dynamic Scoping
Permission updates Manual role change Automatic, per-iteration
Compromised agent Keeps all permissions Tools revoked instantly
New agent onboarding Full access from day 1 Starts in STRICT, earns up
Audit trail Who has which role Why each action was allowed
Granularity Role-level (coarse) Per-tool, per-call (fine)
RBAC vs Dynamic Scoping
==============================

Traditional RBAC:
  deploy agent
  assign role: "power_user"
  ...6 months pass...
  agent is compromised
  agent still has "power_user"
  damage occurs
  incident review finds issue
  admin manually revokes role

DAT Dynamic Scoping:
  deploy agent
  trust: 50 -> ADAPTIVE
  ...earns trust over weeks...
  trust: 75 -> OPEN
  agent compromised
  anomaly detected
  trust: 45 -> ADAPTIVE
  high-risk tools revoked
  investigation triggered
  0 human intervention needed

Time to contain:
  RBAC:     hours to days
  Dynamic:  milliseconds
3
Sandbox Levels
Every
Iteration Checked
11
MCP Servers
45+
Available Tools

Deploy Agents with Guardrails That Scale

Stop choosing between capability and safety. Dynamic scoping gives your agents both.