Least access
Connections start read-only with scoped tokens and service accounts. Write access is opt-in, per integration, per action type.
Safety · Guardrails · Privacy
Safe by design.Private by default.
Autonomy is only useful if you can trust it. Ana sees only what you connect, does only what your policy allows, asks a named human before anything sensitive, and keeps a record of everything.
Privacy-first principles
Six rules Ana
never breaks.
Your data stays yours
No training on your code or data. Run as SaaS, in your VPC, on-prem or air-gapped, with data residency under your control.
A human in charge
Policy decides what Ana may do alone. Anything sensitive waits for the named person your policy names.
Through your process
Ana works through pull requests, pipelines and change windows - your reviews and branch protection still apply.
Reversible by default
Changes ship with a plan and a way back: rollbacks, canaries with automatic rollback, IDE checkpoints.
Everything on the record
Every action, approval and result lands in a decision log you can export as audit evidence.
The guardrail stack
One action,
seven checks.
Scroll to follow a real kind of change - tightening a production IAM role - through every layer before it ships.
action · SRE EngineerLayer 1 / 7
Tighten IAM policy on prod-payments-role
Wiz finding: role grants s3:* on all buckets
- 1IdentityRequest from an authorized team, via SSO
- 2Scope
- 3Policy
- 4Approval
- 5Execution
- 6Verification
- 7Evidence
Layer 01 · Identity
Who is asking?
SAML SSO and role-based access decide who can direct Ana and see its work.
Layer 02 · Scope
Can Ana even reach it?
Ana only touches systems you connected, with the permissions you granted - read-only unless you opted in.
Layer 03 · Policy
Is this allowed, and how risky is it?
Policy-as-code classifies the action. Low risk may proceed; IAM, network, data and production changes are high risk.
Layer 04 · Approval
Who must say yes?
High-risk actions route to the named approvers in your policy - never to Ana itself.
Layer 05 · Execution
How does it ship?
As a pull request with the plan diff, through your CI/CD and change window.
Layer 06 · Verification
Did it work, and nothing broke?
Tests, access analysis and live signals are checked; if anything regresses, Ana rolls back.
Layer 07 · Evidence
Can you prove it later?
The finding, change, approval and verification are recorded and mapped to controls.
What Ana sees
Only what you give it.
- ✓Only the systems you connect
- ✓Only with the scope you grant
- ✓Only for the task in front of it
- ✓In your environment, when you deploy in your VPC or on-prem
What Ana never does
Hard lines.
- ✕Train models on your code or data
- ✕Approve its own high-risk actions
- ✕Bypass your reviews, pipelines or change windows
- ✕Act outside the policy you set
- ✕Run an IDE edit, command or MCP call you didn’t approve
Everywhere Ana works
The same rules, on every surface.
In the platform
Policy gates, named approvers and a decision log around every autonomous engineer.
Guardrails →In the IDE
Approval for every edit, command and MCP call; mode boundaries enforced in code; checkpoints to roll back.
Ana SDE →In your cloud
Deploy in your VPC, on-prem or air-gapped, with data residency and SSO.
Enterprise →On paper
SOC 2 Type II, ISO 27001, HIPAA and GDPR compliant, with reports under NDA.
Trust center →FAQ
Safety and privacy, answered.
Only the actions your policy allows it to take on its own - typically low-risk, reversible ones. Production, IAM, network and data changes wait for a named human approver by default.
See the guardrails live
Autonomy you can actually approve.
We’ll walk your security team through policies, approvals, deployment and the decision log - on your stack.