POLIS
Menu

Specialists, not a generalist

One job per AI employee, and only the rights that job needs.

Each AI employee has its own named account, roles, limits and audit trail. The same rules apply to every role.

01 · Engineering

AI Developer

Takes a Jira ticket assigned to its own account and posts a plan. A named person approves the plan before any code is written.

Powered by Claude: the AI Developer uses Claude as its coding engine, via the Anthropic API or Vertex AI, on your own contract.

  • 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.

  • Draft pull requests only

    Work arrives as a draft pull request on a polis/* branch, with a test summary. Polis never merges.

  • 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.

  • 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.

  • Cost cap per task

    A cost cap per task, per project.

  • 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.

The developer flow, step by step

02 · Access management

Atlassian access manager

Handles access requests in Jira and Confluence: groups, product access and Confluence space permissions. Changes are proposed as a list, approved by a person, then applied and verified.

  • Changes shown as data

    Each change shows the person, the target, and the access level before and after. A person approves the whole set.

  • Approval in the panel or Slack

    Approve in the panel, or in Slack for sets of up to 10 changes. Slack approval is limited to approvers an admin names; by default there are none.

  • Test mode, verify and undo

    Test mode by default, verification by reading each change back, and one-click undo.

  • Verified identity

    A person’s identity is confirmed by verified email, never guessed.

  • No admin rights

    Grants no admin rights while the safety rule “never grant admin rights” is on.

  • Daily summary

    A daily Slack summary for Owners: the access changes made, and any safety rule switched off.

03 · Next

After the pilot: more roles, under the same rules.

  • GitHub access manager

    Access requests for GitHub.

  • More roles

    Further professional roles.

Same rules for every role

Every AI employee works through the same gateway, policies and audit.

  • 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.

  • Append-only audit

    Every decision, approval, tool call and model call is recorded in an append-only audit log.

  • Pause all AI work

    One switch pauses all AI work for everyone, and a banner shows it.

Governance and safety rules Experience and onboarding

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

Email polis@polis.guru