Define the contract
Describe the app intent, actors, sensitive data, allowed actions, approvals, denied paths, brokers, and audit needs.
Generate enforcement artifacts
Create policy evaluators, approval checks, broker guards, route skeletons, audit contracts, and tests.
Validate the contract
Axiom checks that risky capabilities declare the needed policy, approval, broker, disclosure, and audit obligations.
Simulate policy behavior
Run deterministic examples to see when an action should be allowed, denied, or require approval.
Wire the checks into app code
The LLM can draft an action, but generated policy code should decide allow, deny, or approval before execution.
Plain language first. Developer detail second.
Axiom is useful because the same decision can be understood by a product owner, a security reviewer, and a developer. The public layer talks about access, approval, denied actions, and evidence. The developer layer turns those into capabilities, policies, generated checks, route gates, and tests.
capability send_customer_message
policy:
allow if user_requested_message
and destination_is_customer_thread
require_approval if message_contains_sensitive_data
deny if destination_is_external_export
audit:
policy_decision
approval_status
What the contract covers
The goal is not to replace every security tool, and it is not to make a model obedient through longer prompts. The goal is to make the most important agent-facing boundaries visible, generated, testable, and wired into the app.
Data and tools
Which records, APIs, services, and destinations the app or agent-assisted workflow can touch.
Approvals and denies
Which actions need human review, and which actions should never be implemented.
Audit obligations
What decisions, approvals, policy outcomes, and review signals should be captured.