Ravi's security model is built around scoped agent identity, narrow credentials, and clear account boundaries.

## Design Principles

| Principle | What it means |
| --- | --- |
| Identity isolation | Each agent identity has its own communication and credential resources. |
| Scoped API keys | Identity keys are preferred for agent runtime work; management keys are reserved for account-level operations. |
| Server-side enforcement | API requests are authorized against the authenticated user, key scope, and resource ownership. |
| Agent-native auth | Server runtimes can use API keys without desktop apps or interactive unlock flows. |

## API Key Scopes

| Key family | Use for |
| --- | --- |
| `ravi_id_...` | Work scoped to one identity |
| `ravi_mgmt_...` | Account or workspace management operations |

Use the narrowest key that supports the task. For autonomous agents, prefer identity-scoped keys so one leaked key does not expose unrelated identities.

## Identity Isolation

Each identity is a separate operational surface:

- Email inboxes are tied to the identity that owns them.
- Phone resources are tied to the identity that owns them.
- Password and secret entries are identity-scoped.
- Contacts can be queried through the authenticated scope.
- Disabled or deleted identities should no longer be used by agent runtimes.

## Runtime Practices

- Store Ravi API keys only in server-side environment variables or secret managers.
- Do not ship Ravi API keys in browser bundles, mobile apps, logs, or screenshots.
- Use a separate identity per agent, workflow, customer, or environment when isolation matters.
- Rotate keys when an agent environment is decommissioned.
- Use management keys only in trusted backend control planes.

## Request Boundary

All API calls should include an authorization header:

```http
Authorization: Bearer <ravi-api-key-or-token>
```

Use [Authentication](/getting-started/authentication/) for key families and [API Endpoints](/api/endpoints/) for route families.