Security brief
Governed by code, not by prompts.
What a CISO asks first: how AI employees are controlled, isolated, recorded and limited.
This page prints as the security brief.
Certification
Polis has no security certification yet (such as ISO 27001 or SOC 2).
This brief describes the controls in the product, so you can assess them directly.
The control model
One gateway for every external action, and limits no setting can change.
-
One gateway
Every external action goes through one gateway: policy, approval, credential, log.
-
Policy and approvals
Policies per project and action. Where a policy asks for approval, a named person decides and the decision is logged.
-
Never, by code
Enforced in code, and no setting changes it: an AI employee never merges to the default branch, never deploys, and never changes Polis’s own settings.
-
Pause all AI work
One switch pauses all AI work for everyone, and a banner shows it.
Isolation and secrets
No integration credentials in the sandbox, and secrets encrypted at rest.
-
Isolated sandbox
Code and tests run in an isolated sandbox (gVisor on servers). It holds no integration credentials or provider keys, only a short-lived token for its own model calls. Outbound traffic goes only to an allow-list.
-
Short-lived credentials
Short-lived tokens issued per call, limited to one repository for GitHub. Jira and Slack use the connection’s stored credential, which is never exposed to the AI.
-
Envelope encryption
Secrets are protected by envelope encryption under a key-encryption key, with a check that a restore really works.
Identity and access
Named accounts, roles and step-up, for people and AI employees.
-
Named AI employees
AI employees have their own named accounts, roles, limits and audit trail.
-
Roles and two-factor authentication
Seven roles, two-factor authentication (TOTP) for every user, and step-up for sensitive actions.
-
Autonomy per project
Autonomy is set per project: L0 · Advisory, L1 · Supervised, L2 · Autonomous. No AI employee runs above its project’s level, each employee can be capped lower, and approvals can be required for specific actions across the organisation.
Audit and reliability
An append-only record, and a service that keeps running.
-
Append-only audit
Every decision, approval, tool call and model call is recorded in an append-only audit log.
-
Failover
If the coordinating service fails, another takes over within 20 seconds.
Limits and budgets
Every model call priced, and spending capped.
-
Cost cap per task
A cost cap per task, per project.
-
Money budget
A global money budget with reservations. Every model call is priced and recorded, with no prompt or response content stored.
-
Per-employee limits
A cost cap per AI employee, and a limit on tasks per day.
Safety rules
Safety rules on by default, and proof that they hold.
-
Tier 1 safety rules
Safety rules on by default: never grant admin rights; never change Polis’s own accounts or any AI employee’s permissions; never remove the last admin; never create, read or rotate keys, tokens or passwords; never weaken protections Polis relies on. Only your Owner can switch one off, with step-up and a reason. A banner stays on every page while it is off, the change is audited, and a conformance report shows the state.
-
Tier 2 access rules
Access rules per AI employee.
-
Prove it
Polis attempts each safety violation and shows it refused.
Data protection
Where your data is processed, and what Polis keeps.
- In your environment (option A)
- Your data stays in your environment.
- On a dedicated instance (option B)
- One instance per customer, never shared, in the EU.
- Model calls
- Go to your own provider, under your contract, and only for the data classes you allow.
- What Polis stores about model use
- No prompt or response content: usage records hold counts, codes and costs only.
- Company knowledge
- You can export or delete it, and removing a source deletes its stored copy. Retention is your choice. Search runs on a local model, so no document text leaves your installation.
- Data processing agreement
- For the dedicated instance we operate, we sign a data processing agreement with you, available on request.
- Sub-processors for the dedicated instance
- Hetzner Online GmbH (servers, EU). Model providers work under your own contract with them, not ours.
Challenges, honestly
The risks we know about, and how we keep them small.
We would rather tell you than have you find out.
-
AI employees make mistakes
We: draft pull requests only, tests run in the sandbox, your reviewers merge.
You: review time, which we measure in the pilot.
-
Manipulated input
We: the gateway limits every action, an AI employee can never change Polis’s settings, and the sandbox holds no integration credentials or provider keys, only a short-lived token for its own model calls.
You: allowed actions can still be misused, so keep scopes narrow.
-
Approval fatigue
We: approvals only where your policy asks, on plans rather than keystrokes, all logged.
You: named, rotating approvers.
-
Data reaches a model provider
We: only the data classes you allow leave, on your own contract.
You: choosing the data classes and the provider.
-
A new data store
We: experience will be stored in your Polis installation, where you can inspect and remove it, and every lesson will need a person’s approval.
You: your data governance applies to it.
-
An early-stage product
We: the pilot is scoped and reversible.
You: start supervised, on one or two projects.
Book a demo
See it on your own workflow.
A 30-minute call: about 15 minutes of live product, including the pause-all switch, then your questions. Bring your CISO if you like.
What we show
- Roles that can’t overreach, with step-up for sensitive actions
- A model provider locked to a data class
- Approvals by a named person, in Slack or the panel
- The pause-all switch