> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlasent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Developer / API quickstart

> Run a safe AtlaSent evaluation, handle a Permit, verify it, and inspect evidence without implying execution occurred.

## 1. Get a key and seed the demo action

[Create a free account](https://console.atlasent.io/auth/sign-up?utm_source=docs\&utm_medium=quickstart) if you don't have one. Then open **API Keys** in the console, click **New Key**, pick the **Evaluate only** preset, and copy the key. It is shown once. Put it in your shell:

```bash theme={null}
export ATLASENT_API_KEY="ask_live_..."
```

Keys from [console.atlasent.io](https://console.atlasent.io) are **live** keys (`ask_live_...`). The production console does not issue test keys. Keep the key in a secret store, never in examples, source control, or client-side code. [Create an API key](/quickstart/api-key) has the details on scopes.

A live key is accepted only with `context.environment` set to `production`. Any other value (`sandbox`, `test`, `staging`) is refused with `ENVIRONMENT_MISMATCH` before any policy runs, and the refusal is recorded.

Finish the console's setup flow (**Connect my organization**). It seeds a demo `database.execute_sql` action into your organization. That action authorizes nothing real: it returns a decision and executes nothing on its own. It is the safe target for this quickstart.

## 2. Evaluate a protected action

```bash theme={null}
curl -X POST https://api.atlasent.io/functions/v1/v1-evaluate \
  -H "Authorization: Bearer $ATLASENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action_type": "database.execute_sql",
    "actor_id": "dba.alice",
    "context": {
      "environment": "production",
      "sql_text": "SELECT 1",
      "target_database": "analytics",
      "destructive": false
    }
  }'
```

The demo policy allows a non-destructive statement from one of its listed DBAs, so this returns `allow` with a Permit.

The canonical runtime decision is one of `allow`, `deny`, `hold`, or `escalate`.

## 3. Treat the Permit as a bounded execution artifact

If the response requires and includes a Permit, carry that exact artifact to the execution boundary. Do not translate a bare `allow` into permission to execute.

## 4. Verify before the effect

Use the canonical verifier path documented in [Verify a Permit](/quickstart/verify-permit). Verification checks the artifact's authenticity/currentness and applicable binding, expiry, revocation, and replay state.

**Permit verified does not mean execution happened.** It means the execution gate has established the Permit contract required before the effect.

## 5. Inspect evidence

Continue to [Audit export](/quickstart/audit-export) to inspect the decision and verification evidence. Execution/effect is shown only when the applicable observer/provider evidence establishes it.

## Negative tests

Each of these changes one input and must not return `allow`:

* Set `"destructive": true`, or a `sql_text` containing `DROP TABLE` or `TRUNCATE`: `hold`, pending human review.
* Set `"actor_id"` to anything other than `dba.alice` or `dba.bob`: `deny` with `ACTOR_NOT_ALLOWED`.
* Set `"environment"` to anything other than `production`: `deny` with `ENVIRONMENT_MISMATCH`, because the key is live.

<Note>
  The demo action executes nothing, so `"environment": "production"` here only matches your live key. Protecting a real production action is a separate step: provision its action class and policy, then follow the controlled customer acceptance process.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.