Security Model
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:
Authorization: Bearer <ravi-api-key-or-token>Use Authentication for key families and API Endpoints for route families.