Eve Access And Policy

Eve centralizes who can reach a resource and what they can do once they get there. The access model applies to people, applications, agents, endpoint operations, workflows, templates, migration actions, and model provider endpoints when they are used as Eden endpoints. Adam owns the per-seat model-use policy for AI gateway traffic.

Access Layers

Layer	Purpose
Organization	Tenant boundary for all subjects and resources.
Authentication	Proves the caller is a known user, app, or agent.
Control-plane RBAC	Controls who can create, edit, delete, or administer resources.
Data-plane RBAC	Controls who can execute reads, writes, tool calls, and runtime operations.
Endpoint credentials	Credentials Eve uses to connect to the backend. These should not be copied into every client.
Command and request policy	Runtime controls that can observe, warn, mask, or block specific operations.

Identity Types

Eve supports human and machine-oriented access patterns:

Human users authenticate into an organization and receive scoped permissions.
Agents are the public machine-identity model for governed automation and are addressed by agent_uuid in governance APIs.
Service identities use API keys or tokens for automation.
Applications can be represented by agent identities or app-scoped credentials.
Adam and agents should inherit the permissions of the user or subject they represent.

Permission Design

Use least privilege by default:

Create the organization and bootstrap administrators.
Add users and agent identities.
Configure endpoints.
Grant control-plane access only to operators who manage resources.
Grant data-plane access only to subjects that need runtime use.
Test denied paths as well as allowed paths.

Separate control-plane and data-plane access. A user who can query an endpoint should not automatically be able to edit credentials, delete the endpoint, or grant access to others.

Policy Modes

Policy should roll out gradually:

Mode	Behavior	Best use
Observe	Allow the request and record telemetry.	Baseline traffic before enforcement.
Warn	Allow the request and emit warning/audit signals.	Validate a policy before blocking.
Block	Reject the request before it reaches the backend.	Enforce known-dangerous operations.
Mask or redact	Transform sensitive fields before storage or forwarding where configured.	Reduce exposure of secrets or PII.

Examples Of Runtime Policy

Policy can be applied to:

dangerous Redis commands such as flush, shutdown, debug, config, module, or ACL mutations,
PostgreSQL operations with destructive or table-locking behavior,
model or tool requests that include sensitive data,
endpoint operations that violate organization policy,
migration traffic that should remain read-only in a phase,
and agent tool calls that need approval before execution.

Audit Expectations

For customer-ready deployments, make sure policy decisions include:

organization,
subject,
endpoint or tool,
action,
policy outcome,
request metadata,
timestamp,
and enough context for investigation without exposing unnecessary secrets.

Last updated: July 10, 2026