Policy rules
Policy rules reference
Atested's policy is a JSON file: capabilities/policy-rules.json. It's a list of rules evaluated in order. One matched rule is enough to determine ALLOW or DENY.
The policy file
{
"policy_version": "2.0",
"default_decision": "DENY",
"default_reason": "No matching policy rule",
"base_dirs": ["/your/project/root", "/your/runtime/dir"],
"deny_hidden_paths": true,
"deny_executable_outputs": true,
"rules": [ ... ]
}default_decision is what happens when no rule matches. It's DENY. If you remove all rules, everything is denied. This is the fail-closed default.
base_dirs is the list of directories your agent is allowed to work in. File operations targeting paths outside these directories are denied by the outside-base-dirs-deny rule at the bottom of the default ruleset.
deny_hidden_paths and deny_executable_outputs are global constraints. When true, writes to hidden paths (files or directories starting with .) and writes that create executable files are denied even if the action would otherwise be allowed.
Rule structure
Each rule has an id, a description, match conditions, a decision, and a reason.
{
"id": "write-source-allow",
"description": "Allow writes within base dirs (non-hidden, non-executable)",
"match": {
"action_type": ["write"],
"confidence_tier": [1, 2],
"scope": ["local", "repository"],
"target_within_base_dirs": true,
"no_hidden_paths": true,
"no_executable_output": true
},
"decision": "ALLOW",
"reason": "Write within governed scope"
}The match object tests conditions against the classifier's output. All conditions in the match must be true for the rule to apply. If the rule matches, its decision (ALLOW or DENY) is the final answer.
Match conditions
action_type
Matches on the classified action type (read, write, delete, execute, network, move, list, create_directory)
confidence_tier
Matches on the confidence tier (1-4) assigned by the classifier
scope
Matches on the classified scope (local, repository, system, remote, privileged)
target_within_base_dirs
Boolean — whether the operation's target path is within allowed base directories
no_hidden_paths
Boolean — whether the operation targets hidden files or directories
no_executable_output
Boolean — whether the operation would produce an executable file
The default ruleset
The default rules, in evaluation order:
1. tier4-deny
Tier 4 (uninspectable) operations are denied. This fires before anything else.
2. sensitive-path-deny
Operations targeting sensitive paths (scope: privileged) are denied. Catches /etc/, ~/.ssh/, .env, and similar.
3. agent-internal-allow
Agent-internal operations at Tier 1 (TaskCreate, WebSearch, AskUserQuestion, etc.) are allowed. These have no external effects.
4. read-source-allow
Reads at Tier 1-2 within base dirs are allowed.
5. list-source-allow
Directory listings and mkdir at Tier 1-2 within base dirs are allowed.
6. write-source-allow
Writes at Tier 1-2 within base dirs are allowed, with the hidden-path and executable-output constraints.
7. move-source-allow
Moves at Tier 1-2 within base dirs are allowed, with the hidden-path constraint.
8. delete-source-allow
Deletes at Tier 1-2 within base dirs are allowed, with the hidden-path constraint.
9. network-deny
Network operations at remote scope are denied. Curl, wget, ssh, and outbound requests require explicit approval.
10. execute-tier2-allow
Tier 2 executions at local/repository scope are allowed. This covers well-known commands like git, make, pytest that the classifier confidently recognized.
11. tier3-approval-required
Tier 3 (opaque) operations are denied with a reason suggesting you review and approve if appropriate.
12. outside-base-dirs-deny
Anything targeting paths outside base dirs is denied.
If nothing matches, the default_decision fires: DENY.
Every decision record in the chain includes the matched_rule ID so you can see which rule produced the outcome. The matched rule is visible in Activity, Audit Search, the Chain Walker, and Record Detail. In the Configuration window, rules are displayed as readable cards with condition tags rather than raw JSON.
How approvals interact with policy
When an action is denied, you can approve it through the dashboard. An approval is keyed to five fields: artifact_identity, approving_operator, governed_family, deployment_context, and policy_version. The artifact_identity is a SHA-256 hash of the operation's content — its operation name, parameters, and targets.
Once approved, the proxy checks the approval store before applying a DENY decision. If a matching approval exists, the DENY is overridden and the operation is allowed.
Approvals are tied to the exact content of the operation. If the operation changes — different arguments, a different target path — the SHA-256 hash changes, the approval no longer matches, and the operation is denied again. You must review the changed action and decide whether to approve it.
Approvals are recorded in the chain as operation_approval events. Revocations are recorded as operation_revocation events. Both are visible in the Approvals page and the audit trail.
The policy rules
The policy rules (capabilities/policy-rules.json) define how Atested evaluates governed operations: risk levels, allowed parameters, and constraints per action.
The Configuration window in the dashboard shows: the count of active policy rules, configured base directories, discovered operations (classifications the system has learned from observed traffic), and signing status. These reflect the live state of both the policy and the registry.
Start attesting your AI operations
Stop worrying and start knowing in less than five minutes.