Enterprise & advanced controls

Identity, compliance, and hardened controls for larger and regulated deployments — full containment, broader reach, and deeper visibility, available on request.

The core platform is complete enough to run a governed AI workforce. For larger organizations and regulated environments, damn.dev offers an additional layer of enterprise capabilities. These are request-gated — enabled per deployment — rather than switched on by default.

Note — This page describes capabilities you can enable for your deployment, not features that are automatically active on a given install. What your install enforces today is always stated honestly on the Security model pages. Enterprise capabilities are arranged by demand; talk to us to scope what fits.

Identity & access#

  • Single sign-on (SSO / SAML) — connect your identity provider so people sign in with your existing directory.
  • SCIM provisioning — automate joiner/mover/leaver: accounts and roles provisioned and de-provisioned from your IdP.

These slot in alongside the built-in roles and invites rather than replacing them.

Compliance#

  • Compliance packs — a governance baseline applied as a set: it seeds an appropriate policy posture, pre-builds the relevant enforcement rules, and frames the audit export for a given regime.
  • Compliance-grade exports — the audit log's NDJSON export, packaged for review.

Note — Compliance packs set you up with a sensible, regime-appropriate baseline; they are a starting posture you then tune, not a certification.

Hardened containment#

The Security model is candid that the standard install's containment varies by platform. The enterprise hardening tier closes that gap and delivers full containment of the agent:

  • Sovereign egress control — agent network access routes through an allowlist you own, so an agent can only reach hosts you've approved (the per-host control the OS sandbox can't do alone).
  • Scoped credential brokering — tasks receive short-lived, narrowly-scoped credentials instead of standing secrets.
  • Disposable execution sandboxes — risky execution runs in an ephemeral, isolated environment that holds no standing state or credentials.
  • Governed developer environments — the same no-standing-credentials, egress-through-damn.dev model applied to attended coding work.

Together: an agent reaches no standing secrets, can talk to only the hosts you allow, and runs work in an environment that keeps nothing.

Note — Full containment constrains the agent, not you. You still own the perimeter — that's the sovereignty guarantee, not a limitation. We'll always state exactly what a given option enforces; see Honest claims & reporting.

Reach beyond your own box#

  • Govern agents wherever they run — the same rules and the same audit trail follow an agent whether it runs inside your deployment or out on the machines your team actually uses. Not just an inventory of what's out there, but control over what it can do.
  • See into the AI itself — inspect what your agents are actually sending and receiving, on infrastructure you own — the depth of visibility a cloud vendor can only offer from inside their cloud, done sovereignly inside yours.

Getting these#

Enterprise capabilities are entitlement-gated and enabled per deployment. The fastest path is a short scoping call. To make it productive, come with:

  • Your identity provider (for SSO / SCIM) — which IdP and protocol.
  • Your egress targets — the hosts and services your agents legitimately need to reach, so we can shape the allowlist.
  • Your compliance regime(s) — so we match the right policy baseline and audit framing.
  • Where it runs — your install path and environment (cloud, on-prem, air-gapped).

With that, we can scope the hardening tier to your environment and get moving.

Next#