AgentScope — purpose-bound authorization
An allowlist of tools says what an agent can call. It does not say what the agent is for, what it must never do, or which data it may touch. AgentScope adds those dimensions to the agent identity and enforces them in the same deterministic PDP — so authority is bound to the declared job, not just a list.
Astrix governs the credentials agents use. Unveilr governs the agents themselves.
Added value
| Allowlist only | Purpose-bound (AgentScope) |
|---|---|
| "Which tools is it allowed to call?" | "What is it for, and what may it never do?" |
| A drifted agent inside its allowlist looks fine | A forbidden tool is denied even when the allowlist admits it |
| Data exposure is invisible to the gate | A target outside the agent's data scope is denied |
| Anyone can ship a prod agent with no stated purpose | A production agent can't be approved without a declared purpose |
| Audit shows what tool, not why | The declared purpose is bound to every action in the evidence trail |
The four dimensions
Every AgentIdentity carries, alongside its allowedTools scope:
| Field | Meaning | Enforcement |
|---|---|---|
purpose | The agent's declared objective | Required before a production agent is approved; sealed onto every decision |
forbiddenTools | An explicit denylist | Denied even when allowedTools would admit it — allow ∧ ¬deny |
dataScope | Data classes the agent may touch | A target whose data classes exceed the scope is denied |
environment | production / staging / development | Gates the production-purpose requirement; recorded for audit |
How it decides
The PDP evaluates these deterministically, in order, before tenant policies:
- Tool scope — not in
allowedTools→deny(fail closed). - Forbidden denylist — matches
forbiddenTools→denywith reason codeFORBIDDEN_TOOL. This overrides the allowlist: an agent scoped to*still cannot call a forbidden tool. - Data-scope binding — the resolved target carries a data class outside
dataScope→denywith reason codeDATA_SCOPE_DRIFT(best-effort: only when the target's data classes are known). - Then the usual request-detection backstop and tenant policies apply.
No model call, no clock read — the same explainable, reproducible engine that powers Govern, so the decision is replayable and audit-signable.
Purpose in the audit trail
The proposal's agent-native audit model is purpose · tool · credential ·
resource · timeline. Govern binds the declared purpose to each action: every
policy_decision evidence event records agentPurpose, so "why was this agent
allowed to do this?" is answerable from the sealed ledger, not reconstructed
after the fact. See Prove.
Where it fits
- Pair it with Credential mediation: a purpose-bound agent that also receives only short-lived scoped credentials has the least authority for the least time — the smallest possible blast radius.
- Registration/approval and the deployment gate live in Govern; AgentScope simply makes the gate purpose-aware.