Filesystem read
read, get, fetch, load, cat, view, show, inspect
Agent governance
Your agent connects. Governance is live immediately.
Any AI agent that makes tool calls can be governed through Atested. The agent connects, its tools are automatically discovered and classified into governance categories, and every action produces a signed, immutable record. No manual mapping. No per-agent configuration. No integration work.
How automatic onboarding works
When an agent calls a tool that Atested hasn't seen before, the system classifies it automatically. Tool names are pattern-matched to governance categories — read_file maps to filesystem read, run_shell maps to high-risk write, send_email maps to messaging. The classification is persisted so subsequent calls resolve instantly.
The agent doesn't need to know about Atested. It doesn't need a plugin, an adapter, or a modified tool list. It calls /api/evaluate with an action name and a target, and gets back an ALLOW or DENY with a full governance record.
auto-classification.json
CLASSIFIED
{
"decision": "ALLOW",
"reason": "Action meets all required conditions.",
"record_hash": "sha256:a1b2c3d4e5f6...",
"classification": {
"auto_classified": true,
"original_tool": "RUN_SHELL",
"classified_as": "FS_WRITE",
"classification_reason": "pattern_match:run"
}
}
First time Atested sees
run_shell, it classifies it as a high-risk filesystem write. The classification is returned in the response and persisted for future calls.
Classification categories
Every tool maps to a governance category
Atested maintains 10 governance categories that cover the operations AI agents perform. Unknown tools are classified by keyword matching on the tool name. If no pattern matches, the tool defaults to the highest-risk category and is logged for operator review.
Filesystem write
write, put, save, store, create, append, output
Filesystem delete
delete, remove, rm, unlink, erase, purge
Directory listing
list, ls, dir, find, glob, scan, enumerate
Move & copy
move, rename, copy, duplicate, clone, mkdir
Messaging
send, post, publish, notify, reply, respond
Execution / shell
exec, run, shell, bash, command, spawn, invoke
Classified as high-risk write by default.
No pattern match
Tools that don't match any keyword pattern are classified as high-risk writes and logged for operator review. The operator can override the classification at any time.
Learned mappings
Every classification is persisted. On restart, previously seen tools resolve from the mapping file — no re-classification, no cold start.
Proof point
Tested with Zora: 160+ tools, zero configuration
Zora is an autonomous AI agent with over 160 tools spanning filesystem operations, shell execution, web requests, code analysis, and more. It was connected to Atested's governance endpoint with no prior configuration — no tool mapping file, no Zora-specific adapter, no code changes on either side.
On the first request, every Zora tool was automatically classified into the appropriate governance category. Filesystem reads were recognized as reads. Shell commands were classified as high-risk writes. Directory listings were classified as listings. The full governance chain — evaluation, signed records, audit trail — was operational from the first call.
Zora's tool names bear no resemblance to Atested's internal registry. That's the point. The classifier doesn't need tool names to match — it needs them to contain recognizable operation keywords, which nearly all tools do.
zora-governance-session.jsonl
GOVERNED
{
"original_tool": "RUN_SHELL",
"classified_as": "FS_WRITE",
"decision": "ALLOW",
"target": "/project/scripts/",
"record_hash": "sha256:4e5f6a7b..."
}
{
"original_tool": "READ_WEBPAGE",
"classified_as": "FS_READ",
"decision": "ALLOW",
"target": "/project/README.md",
"record_hash": "sha256:8c9d0e1f..."
}
160+ tools governed automatically. Same signed chain. Same audit trail. Same proof artifacts. Zero integration work.
Integration surface
One HTTP endpoint. That's the entire integration.
Your agent infrastructure sends a POST to /api/evaluate with the tool name, target path, and optional evidence. Atested returns a governance decision with a full audit record. Bearer token authentication.
This is not an SDK, not a library, not a framework plugin. It's a single HTTP call that any language, any framework, any orchestrator can make. The governance layer is decoupled from your agent implementation.
evaluate-request.sh
HTTP API
curl -X POST http://localhost:8000/api/evaluate \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"action": "run_shell",
"target": "/project/deploy.sh",
"evidence": {
"goal": "Deploy staging build"
}
}'
Returns
{"decision": "ALLOW", "record_hash": "sha256:...", "classification": {...}} or {"decision": "DENY", "missing": [...]}. The decision is recorded in the governance chain regardless of outcome.
Governance invariant
Unknown tools are classified and evaluated, not rejected
This is a governance design commitment, not a feature flag. The evaluate endpoint must never return immediate DENY solely because a tool name is unrecognized. If your agent has a tool Atested hasn't seen before, it will be classified, evaluated against the same policy as every other tool, and produce a signed governance record. This is codified as INV-009 in the governance invariants.