Z User
136379c666
- 18 agent specs across Software, Support, Marketing, Cross-cutting (orchestrator + 7 software + 5 support + 3 cross-cutting + leads-finder) - 8 reusable skills (handoff, pr-review, dokploy-deploy, campaign-structure, content-calendar, ticket-triage, license-lifecycle, invoice-draft) - 3 JSON schemas: handoff, deliverable, approval - Policies: autonomy levels, tool risk classification, compliance (DSGVO/GoBD/UWG) - routing.toml: model tiers T1/T2/T3 + provider config (PII gating) - Rust workspace (5 crates, all compile + 16 tests pass): - aos-mcp: tool registry + risk tagging - aos-policy: autonomy levels, budget enforcement, approval requests - aos-license: ed25519 license issue/verify (real crypto + CLI binary) - aos-ledger: integer-cents money math, gapless numbering, VAT, audit chain - aos-sync: frontmatter validator (18/18 specs pass), CLI binary - CLAUDE.md entry point with architecture overview + roadmap
48 lines
1.7 KiB
Markdown
48 lines
1.7 KiB
Markdown
# Tool Risk Classification
|
|
|
|
Every tool exposed via `aos-mcp` (or any MCP server agents use) carries a
|
|
`risk` tag in its manifest. The policy crate enforces that an agent's
|
|
`allowed_tool_risk` (derived from its tier) permits the call.
|
|
|
|
## Risk: low
|
|
|
|
Read-only, idempotent, no external side effects, no PII exposure beyond what
|
|
the agent already has context for.
|
|
|
|
Examples: `aos:read_task`, `aos:read_client`, `github:read_pr`, `git:log`,
|
|
`web:search`, `seo:crawl_public`.
|
|
|
|
Any tier (T1/T2/T3) may call these.
|
|
|
|
## Risk: medium
|
|
|
|
Internal writes that are reversible, or reads that touch PII / financials.
|
|
|
|
Examples: `aos:create_task`, `aos:update_task`, `aos:create_note`,
|
|
`aos:draft_invoice` (draft, not sent), `github:create_branch`,
|
|
`dokploy:restart_staging`.
|
|
|
|
T1 and T2 may call directly. T3 must have a T1/T2 reviewer pass on the
|
|
deliverable before these are committed.
|
|
|
|
## Risk: high
|
|
|
|
Irreversible, external, or money-moving. **Always produces an approval
|
|
request** regardless of tier. The policy crate will not execute one without
|
|
an approved `ApprovalRequest` of matching action type.
|
|
|
|
Examples: `ads:spend`, `ads:activate_campaign`, `aos:send_invoice`,
|
|
`aos:revoke_license`, `aos:delete_instance`, `dns:delete_record`,
|
|
`dokploy:deploy_production`, `github:merge_to_main`, `db:migrate_live`,
|
|
`ledger:finalize_period`, `elster:submit`.
|
|
|
|
No tier auto-executes these. T1 may *request* them (producing the approval);
|
|
approval is always human.
|
|
|
|
## Per-agent enforcement
|
|
|
|
An agent spec's `tools` frontmatter lists allowed tools explicitly. A tool
|
|
not listed is forbidden — the agent cannot call it even if its tier would
|
|
otherwise permit it. `forbidden` is an explicit denylist (e.g. an ads worker
|
|
that may read campaigns but must not activate them).
|