Wrong target
An agent may touch production when the human expected a dev, staging, or local environment.
Too much access
A token or API key may allow more than the agent actually needs for the task.
False confidence
Generated code, tests, or status reports can look plausible while hiding missing checks or unsafe behavior.
Prompts are not governance.
Prompts, README files, AGENTS.md files, and team instructions are useful, but they are guidance. They can be ignored, contradicted, forgotten, or interpreted differently by different models.
The common problem
- Rules live in chat, comments, docs, middleware, tests, and memory.
- The agent sees a goal, but not always the real boundary around that goal.
- Approval and data rules are discovered too late in the build process.
- The human reviews the result after the risky path has already been created.
Axiom moves key rules into the project.
Axiom gives teams a durable place to define what the app can touch, what actions exist, when approval is required, what external tools may run, what is denied, and what evidence must be captured.
capability delete_customer_data
policy:
require_approval if production_target
or irreversible_action
deny if approval_missing
or backup_not_verified
or agent_requested_broad_delete
audit:
policy_decision
approval_state
never log raw_customer_record
Declare capabilities
Agents should not invent new data access or destructive actions while implementing a feature.
Require approval
Production changes, external effects, sensitive disclosures, and irreversible operations need explicit gates.
Audit safely
Humans need a durable record of what happened without storing raw secrets, payment data, or private records.
What Axiom does not promise
Axiom is not a backup system, sandbox, deployment firewall, or production permission manager by itself. It is the application contract layer that helps humans and agents define risky behavior before implementation.
Still required
- separate dev, staging, and production environments
- least-privilege credentials
- backups stored away from the thing being deleted
- human review for high-risk changes
- runtime and infrastructure controls
Sources
These reports are examples of the failure class. Axiom references them carefully: it could help model and test the risky capabilities, but it would not be a complete safety solution by itself.