# Darkoza Intent-Bound Agent Authority — pilot v0.2

**Date:** 2026-11-03  
**Environment:** primary CPU-only research node, Python 3.14.4; private host identifiers withheld  
**Status:** Research prototype; NOT production integrated; NOT a security certification.

## Objective

Test a narrow, defensible hypothesis: a model should propose an action, but the model must not confer authority on itself. A deterministic policy gate should allow or deny an action using a short-lived grant bound to a principal, tenant, task, audience, exact tool, capability, action, resource and digest of the exact effect payload. High-risk effects require a separate verified approval. The gate never executes tools.

## What v0.2 implements

- Explicit tenant / principal / task / audience binding.
- Exact tool, capability, action and resource allowlists; no wildcards.
- Grant expiry, maximum TTL and revocation state.
- Action risk assigned by policy, never by the model or untrusted payload.
- SHA-256 digest of the exact effect-bearing intent (including tool and effect digest).
- A required idempotency key for all mutating actions; repeated use is rejected while the process is alive.
- High/critical actions (external_send, delete, payment, credential_change, network_change) require approval bound to the exact intent, exact tenant/principal/task and short validity window.
- An external verifier callback is mandatory for high-risk approvals. Missing, failed or throwing verifier fails closed.
- In-process, lock-protected, one-time approval replay protection.
- Integrity receipt with stable reason codes. Receipt hash is an integrity checksum only, not a signature, identity proof or non-repudiation.
- No tool executor, network access, credential use, persistent store or production endpoint.

## Experimental validation

- Python compilation: passed.
- Unit tests: **37/37 passed**.
- Concurrent replay: 24 simultaneous evaluations of the same approved action yielded exactly one allow and 23 replay denials.
- Mutating idempotency replay: first in-process use allowed, second use denied.
- Wrong tenant, principal, task, audience, tool, capability, action, resource, invalid effect digest, wildcard scopes, grant expiry, revocation, bad approval, expired approval, reused approval and receipt tampering were tested.
- Local microbenchmark: 50,000 in-memory scoped-read policy evaluations after 1,000 warm-ups. Median **32.389 μs**, p95 **48.763 μs**, p99 **77.711 μs**. This measures the Python policy evaluator and receipt digest only; not end-to-end request latency, network, cryptographic signature verification, DB persistence or tool execution.

## Critical limitations / production gates

1. **Identity:** the prototype accepts already-constructed dataclasses. It does not authenticate a user, service or agent. Production must integrate a real IdP/OAuth/OIDC resource server and verify agent-to-user delegation.
2. **Approval cryptography:** the callback is a contract only. Tests use a simple deterministic callback; production requires verified human identity, strong authentication where appropriate, signed/nonce-bound consent and approver policy.
3. **Persistence and crash recovery:** revocation, approval replay and idempotency state live in process memory. A restart loses them. Production requires durable, transactional, shared state with retention, concurrency and recovery tests.
4. **Execution boundary:** this library does not launch tools. Production must place a separate sandboxed executor after a successful gate; the executor must consume the exact effect digest that was approved and refuse payload substitution.
5. **Effect canonicalization:** this prototype accepts an externally calculated SHA-256 digest. A production adapter must canonicalize typed tool arguments and compute the digest at the trusted gateway, not accept a digest supplied by the model/client.
6. **Risk policy:** the action taxonomy is a small pilot set; production needs per-tool impact analysis, explicit reversibility, data sensitivity, financial thresholds, external recipients and step-up policy. "write" is only medium-risk in this test table and must not be used as a generic permission for arbitrary writes.
7. **Resource scope:** identifiers are exact strings. Production requires typed resource identifiers and robust authorization for hierarchical resources, ownership and delegated access.
8. **Audit:** the receipt digest is not a signed log. Production requires append-only, access-controlled, tamper-evident audit events and periodic export/verification.
9. **Abuse and availability:** policy rate limiting, workload fairness, queueing, provider backpressure and denial-of-service protections are separate from user request-count quotas. Darkoza's no-hard-chat-request-count policy must not be implemented as unbounded compute.
10. **Red-team / independent review:** no external penetration test, independent code review, AgentDojo/InjecAgent benchmark execution, production shadow deployment or customer field trial has been done.

## Proposed production contract

authenticated_identity + delegated_authority + intent + exact_effect  
→ policy decision  
→ draft / approval request / deny  
→ durable one-time authorization  
→ sandboxed capability-scoped executor  
→ independent result verification  
→ evidence receipt + usage meter + audit event.

The model may suggest a plan or action; only the trusted policy and authenticated user can grant authority. User confirmation must display the exact action, tool, resource, payload/effect, recipients, cost and reversibility before approving.

## Files

- authority_gate.py: standalone policy-evaluation prototype.
- test_authority_gate.py: 36-unit-test suite.
- benchmark_authority_gate.py: reproducible local microbenchmark.
- benchmark_results.json: measured output.
- README.md: this record.

## Disposition

**Research prototype completed and locally verified; not deployed to public product or connected to production tools.** No changes were made to ASI Gateway, Cognitive core, product UI, database, identity, payments, API catalog, DNS, firewall, or system services.