Devin Formal

Devin security: give Devin access without shared secrets

Devin by Cognition authenticates to Formal with its own short-lived OIDC token, not a shared database password. Each Devin session maps to the person who started it, reaches your database only after that person approves in Slack, and is logged through the Connector.

Get a demo ›Read the docs ›

devin session · formal-db.shexample

$ scripts/formal-db.sh psql -c 'SELECT 1'
BLOCK    Devin is blocked by default; request JIT access
$ scripts/formal-db.sh request 'verify Formal JIT access' 5
{"triggered":true,"runId":"..."}
# Slack DM from the Formal app to the requesting user: Yes
APPROVED Devin database access approved. Access expires in 5 minutes.
$ scripts/formal-db.sh psql -c 'SELECT 1'
(1 row)
# Logs: machine user devin, end user [email protected], claims under user.oidc.claims

How Devin gets database access

Devin proves who it is
Each Devin session gets a short-lived OIDC token. Formal checks it against your Devin organization ID and maps it to a devin machine user and to the person who started the session.
Blocked by default
A policy blocks the devin machine user on the Connector. When Devin needs data, it calls CreateWorkflowTrigger with a reason and a duration.
Approved in Slack
The Formal app asks the requesting user in a Slack DM. Yes creates a policy suspension for that person and that Devin session only, until the requested duration ends.
Queried through the Connector
Devin mints a short-lived federation token for each connection and runs psql through the Connector. Your other policies still apply, and logs name both the machine user and the human.

What Formal enforces on Devin

PAM

No shared database password

Devin mints a federation token for each connection. It expires with the OIDC token it came from, after one hour at most.

PAM

A person behind every session

The requesting user's email resolves to a Formal user. The Connector evaluates and logs each session with that person as the end user.

PAM

Devin can't approve itself

A separate workflow machine user creates suspensions, and a Control Plane Permission limits Devin to two calls: CreateWorkflowTrigger and CreateFederationToken.

PAM

Access ends with the session

The suspension matches one Devin session and expires after the approved duration. A new session needs a new approval, and deleting the suspension revokes it at once.

Endpoint

Policy on outbound HTTPS

The headless Endpoint runs in the Devin VM with Transparent Mode set to fail closed, and evaluates your policies on the destinations your network rules match.

Endpoint

Humans merge pull requests

A documented policy blocks the GitHub GraphQL mutations and the REST call that merge or auto-merge a pull request, for traffic from Devin's machine user.

A shared database password in the Devin environment gives every Devin session standing access, with no record of who asked for it. Formal replaces that password with Devin’s own short-lived OIDC identity, a Slack approval for each session, and logs that name the person behind the agent.

What does Devin security with Formal cover?

Devin by Cognition runs each session in its own VM, with whatever credentials you put in its environment. Devin security with Formal covers the two paths that matter most: database queries, which go through the Formal Connector (PAM), and outbound HTTPS from the Devin VM, which goes through the Formal Endpoint installed in the environment.

For Devin AI security, the point is that neither path depends on a static key stored in Devin. Both authenticate with Devin’s OIDC token, both evaluate your policies, and both attribute each action to the human who started the Devin session.

How does Devin OIDC authentication work?

Every Devin session gets a short-lived identity token signed by Devin, with claims such as org_id, devin_id and requesting_user_email (Devin’s OIDC documentation). Cognition’s setup-devin-oidc action installs the devin-oidc CLI, which exchanges the session token for a token scoped to your Formal integration’s audience.

In Formal, you create an OIDC integration from the Devin preset (issuer https://app.devin.ai), restrict it to your organization with claims.org_id == "<DEVIN_ORG_ID>", and map it to a devin machine user. The preset’s End-User Email Expression, claims.requesting_user_email, resolves the requesting user to a Formal user; if no Formal user matches, Formal mints no database credential. We explain why we built this in Giving Cloud Agents Production Access with OIDC, Not Secrets.

Just-in-time database access for Devin, approved in Slack

Devin starts with no database access. A policy blocks the devin machine user by default, and access opens for one Devin session after the person who started it approves. That is just-in-time access built from two platform pieces: a workflow that asks in Slack, and a policy suspension that expires.

The scope comes from verified token claims, never from the request. The suspension matches the requester’s email and the devin_id claim. Devin writes the request payload (its reason and the requested duration), so the guide keeps those fields out of the suspension’s match condition, and the approver sees both in Slack before saying yes.

The guide sends the request to the person who started the session; the workflow’s ask-in-chat action can also target a Slack channel or a list of approvers. For the policy, the Permission, the workflow and the formal-db.sh script Devin runs, follow the guide to give Devin just-in-time database access.

How do you control what Devin sends out?

Install the Endpoint’s headless Debian package in your Devin environment blueprint, with oidc.provider = "devin" and Transparent Mode set to fail closed. The package ships a formal.service systemd user unit that Devin snapshots keep, so every later session starts the Endpoint automatically.

Here’s the limit to know: the Endpoint passes a connection through untouched unless a network rule matches it, so you choose which destinations it inspects. The documented example matches github.com and api.github.com for Devin’s machine user and blocks merging and auto-merge, so a human still merges. The cloud agents guide covers the setup, shared with Cursor Cloud Agents. On laptops, network rules can match the Devin CLI process with process.is_devin_cli.

What does a Devin enterprise rollout need?

Matching identities. Every Devin user needs a Formal user with the same email address, and needs to be in the Slack workspace connected to Formal.
A reachable Connector. The Devin VM must reach the Connector listener in front of your Postgres resource. If the Connector is on a private network, connect the VM to it, for example with a Tailscale subnet router.
The right issuer. The Devin preset uses https://app.devin.ai. As of November 2026, Cognition documents a separate issuer URL for enterprise deployments on a custom domain, so confirm yours with your Devin administrator first.
Infrastructure as code, if you want it. The whole setup maps to the Terraform resources formal_user, formal_integration_oidc, formal_permission, formal_policy and formal_workflow.

Frequently asked questions

Can Devin access our production database safely?

Yes, when access is the exception and not the default. With Formal, a policy blocks Devin’s machine user, Devin requests access with a reason, and the person who started the Devin session approves it in Slack. The approval covers that session only, expires after the requested duration, and your masking and read-only policies still apply. The Devin database access guide has the full setup.

Can Devin approve its own access request?

No. The Slack approval goes to the requesting user, and a separate workflow machine user creates the policy suspension. A Control Plane Permission limits Devin’s machine user to CreateWorkflowTrigger and CreateFederationToken, so Devin can ask for access and mint credentials, but it can’t create suspensions or change policies.

How long does Devin's database access last?

For the approved duration, and only for the Devin session that asked. Devin proposes the duration and the approver sees it in Slack before saying yes. Each database credential Devin mints expires with its OIDC token, after one hour at most, and deleting the suspension in Formal revokes access immediately.

Does data masking still apply to Devin?

Yes. The approval only suspends the policy that blocks Devin by default. Every other policy on the Connector still evaluates the session, so data masking and read-only rules apply to Devin. Connector policies can also read Devin’s token claims, such as devin_id, under input.user.oidc.claims.

Do we need to store database passwords in Devin?

No. The Devin environment holds identifiers only: the Formal integration audience, the workflow ID and the Connector host. For each connection, the access script mints a short-lived federation token from Devin’s OIDC token and passes it to psql as the password. Nothing long-lived sits in Devin’s secrets for this path.

Ready to (zero) trust your agents?

One network security layer for every agent and human, from the laptop to production.

Get a demo ›