Security
How we protect the data that flows through Arrakis.
We are a security product. Our own security posture needs to hold up to the same scrutiny we ask enterprises to apply to their AI agents.
Core Principles
Four principles that shape how we are built.
Minimum necessary data
We process what is needed to enforce policies and generate audit records. We do not process the content of agent inputs or outputs unless you explicitly opt in for debugging. Metadata about actions, not the data acted upon.
Tenant isolation
Each customer's agent event data, policy store, and audit log exist in logically isolated partitions. Cross-tenant reads are architecturally prevented at the storage layer, not just by application logic.
Least-privilege access internally
Our own engineers follow the same principle we enforce on AI agents: access is scoped to what the role requires, not what is convenient. Production access requires break-glass justification with audit logging.
Transparency about what we retain
We tell you what we store, for how long, and where. Enterprise customers can request data residency in specific regions. All customers can export or delete their data on request.
Data Handling
What we store and what we do not.
What Arrakis stores
- Agent action metadata: action type, timestamp (UTC), resource target path, and policy outcome (permitted/blocked/throttled)
- Session identifiers: agent ID, session ID, environment tag
- Policy configuration and policy change history
- User account data: name, email, team membership
- Billing records as required for invoicing and tax compliance
What we do not store by default
- The content of agent prompts or completions
- The body of agent API requests or responses
- File or document content that an agent accessed
- Database row contents or query result sets
- Any data that would constitute HIPAA-covered health information
Debug mode is opt-in and scoped
Customers who want to capture agent input/output content for debugging purposes can enable debug mode on a per-agent, per-session basis. Debug captures are stored in a separate partition, retain for a maximum of 7 days, are not used in policy enforcement, and can be deleted on request at any time.
Enterprise Controls
Controls available to enterprise customers.
Professional and Enterprise plans include additional access control and data governance options for organizations with stricter requirements.
SSO and SAML 2.0
Integrate Arrakis with your identity provider. Okta, Azure AD, and generic SAML 2.0 IdPs are supported on Enterprise plans. User provisioning via SCIM is on the roadmap.
Data residency options
Enterprise customers can select US or EU region for agent metadata processing and log storage. This covers the Arrakis-managed infrastructure; your agents and agent runtime remain in your own environment.
IP allowlist for API access
Restrict which IP ranges can access the Arrakis REST API and dashboard. Useful for organizations that restrict cloud management tool access to corporate network ranges.
SIEM-compatible log export
Stream agent event logs to your SIEM in structured JSON. Webhook delivery and direct Splunk/Elastic connectors are available on Enterprise plans. Useful for teams with a centralized security operations practice.
Role-based access control
Fine-grained team roles: Admin, Operator, Analyst, and Read-only. Policy creation and deletion are limited to Admin. Analysts can view and export logs without modifying policies.
Compliance reporting packs
Pre-formatted evidence exports for SOC 2 readiness reviews and GDPR data subject access requests. Scoped to a defined date range and formatted for handoff to your audit team or external assessor.
Disclosure
Responsible disclosure.
We take security reports seriously and respond to them within 2 business days. We do not pursue legal action against good-faith researchers reporting vulnerabilities in accordance with this policy.
What to report
We are interested in vulnerabilities in the Arrakis console web application, the Arrakis API surface, the Python SDK, the HTTP proxy component, and our authentication and authorization implementation. Reports about third-party software running in our infrastructure (upstream packages, cloud provider infrastructure) are welcome but may be redirected to the relevant maintainer.
What to include
A clear description of the vulnerability, steps to reproduce, the potential impact, and any evidence you have gathered. Please do not include proof-of-concept exploit code that could cause damage if mishandled. A written description of the technique is sufficient.
What we do not accept
Reports about rate limiting that require impractical request volumes, missing DMARC or SPF records (we have both), clickjacking on pages without sensitive actions, and issues that require physical access to a device we control.
Contact
Send reports to [email protected]. We aim to acknowledge within 2 business days, provide a timeline within 10 business days, and notify you when a fix is shipped so you can coordinate disclosure timing with us.
Security questions from your team?
Enterprise procurement teams often have specific questions about our controls. We are happy to provide a security overview document and answer questions directly.