Skip to main content
Fastest path (about 5 minutes): create a free account, then follow the Developer / API quickstart: one request to a demo action that returns allow, then the hold and deny variants. Other paths: Choose your AtlaSent quickstart.

Developer / API

Evaluate a sandbox action, handle a bounded Permit, verify it, and inspect the evidence that actually exists.

Enterprise operator

Take one protected action from organization setup through rehearsal and readiness review.

AI agent / MCP

Put AtlaSent between an agent tool request and a consequential effect without treating tool access as authority.

​
The lifecycle you are learning

Verified identity → organizational authority → authorization → Permit → verification → execution → evidence Each stage establishes something different. An allow does not prove execution. A verified Permit does not prove the downstream effect occurred.

​
Existing developer sequence

The detailed developer references remain available:
  1. API key
  2. First evaluation
  3. Verify a Permit
  4. Inspect/export available audit evidence
Portable signed evidence bundles and offline third-party bundle verification must not be described as generally available unless the current Trust Portal and compliance claims matrix say they are. Follow those sources for current maturity.
The Developer / API quickstart uses a demo action that executes nothing. Console keys are live keys, so its requests send context.environment: "production"; that names the key’s environment and activates nothing. The other paths have their own safety guidance: follow the page you choose. Protecting a real production action is a separate, controlled step.