On behalf of a person
The agent carries a delegated token bound to that person's session. It never receives their credentials, cannot mint a token, cannot choose which identity it acts as, and ends when their session ends.
Your agents get the same guardrails as your people.
Identity, authorization, classification, isolation, and audit apply consistently across the interface, APIs, and agents.
Identity
Authentication stays with your identity provider.
Authentication is always delegated to the customer's identity provider — OpenID Connect with Microsoft Entra ID as a first-class provider, SAML federation, and OAuth 2.1 for programmatic and agent access. Aevah is never a place where credentials live.
Authorization context
Two contexts, never combined.
As a service agent
A first-class principal governed exactly like a user account: a named human owner, administrator-assigned permissions, its own lifecycle, independent revocation, and its own identity in the audit trail.
There is no third mode, no ambient authority, and no anonymous path to governed data. Permissions are never pooled across a chain — a parent agent can narrow a task, never widen it.
Execution-time authority
Authority is resolved at execution.
Every consequential operation re-resolves the caller's current roles, permissions, record scope, and field authority at the moment it runs. A permission revoked seconds ago is already gone. Revocation at the identity provider cascades immediately, and permissions are enumerated explicitly — never wildcarded.
Data classification
Classification is enforced on output.
| Tier | Access | Export | Access logging |
|---|---|---|---|
| Public | Unrestricted | Allowed | — |
| Internal | Standard access control | Allowed | — |
| Confidential | Role-gated | Allowed | Every access |
| Restricted | Role-gated | Blocked — cannot leave the platform boundary | Every access |
Classification applies identically to interface, API, and agent calls. Values a caller may not see cannot influence anything they can see — not counts, not facets, not sort order, not derived results.
PII is an independent flag applied alongside classification. External model inference is limited to Public and Internal non-PII content; anything more sensitive fails closed rather than degrading.
Isolation
Every customer runs a discrete instance.
Every customer runs a discrete instance at its own URL — self-hosted in the customer's own environment, managed by Aevah in a region the customer selects, or sovereign and air-gapped with no external egress. There is no shared data plane between customers.
Cross-customer access isn't denied by a rule that could be misconfigured. The data isn't present to reach.
Vendor access
No standing access to customer data.
For Aevah-managed instances, Aevah personnel hold no standing access to customer data. Support access is requested, customer-approved, time-boxed, scoped to the issue, and recorded in the customer's own audit trail.
Audit
The control record stays inside your boundary.
Aevah audits sign-in outcomes, authorization denials, delegation issuance and termination, agent lifecycle and permission changes, every access to Confidential and Restricted data, every governed change, approval decisions, and export attempts including blocked ones. Records are immutable — they can be added to, never altered or deleted, including by administrators. Retention is customer-configured and records stay within the customer's own boundary.
Aevah is designed against ISO/IEC 27001, NIST SP 800-53 AC-16, SOC 2 CC6, and PCI-DSS classification requirements. Full control detail is provided during RFP and pilot.
Error contract
Denials state what was required, never what exists.
An error never reveals the presence or content of a record you may not see.
401 — no valid identity
{ "status": 401, "error": "unauthenticated",
"message": "No valid identity was presented.",
"correlationId": "3f9c1a7e-..." }403 — authenticated, lacks the permission
{ "status": 403, "error": "forbidden",
"message": "Permission 'connected_system.manage' is required.",
"requiredPermission": "connected_system.manage",
"correlationId": "8b21d4c0-..." }403 — policy denial
{ "status": 403, "error": "policy_denied",
"message": "Export is not permitted for Restricted content.",
"policy": "classification.export",
"classification": "Restricted",
"correlationId": "c47a09fe-..." }409 — approval required
{ "status": 409, "error": "approval_required",
"message": "This change requires steward approval before execution.",
"proposalId": "prop_9d3f21",
"requiredPermission": "steward.approve_merge",
"correlationId": "5e8f3b12-..." }A practical next step
Request the security and integration detail pack.
Full control and integration detail is provided during RFP and pilot.
Request the detail pack