Identity and Trust

AIP carries rich identity context, but data inside an envelope is not trusted merely because it is well formed. Production security begins when a transport identity is verified and mapped to server-owned context.

The Actors in One Action

One operation may involve several distinct identities:

Identity	Meaning
Authenticated principal	Entity proven by the transport or signature
Human actor	Person who initiated or owns the intent
Service account	Machine identity executing the operation
acted_on_behalf_of	Principal whose authority is being exercised
Tenant	Isolation and policy boundary
External account	Product account used by the connector
External user	Product-local user associated with the action
Credential reference	Opaque handle to secret material held elsewhere

Keeping these identities separate prevents a service token from being mistaken for the human who approved a refund or changed an account.

Principal Claims versus Authentication

Envelope.from, ApprovalDecision.approver, and action identity fields are claims supplied on the wire. The edge must bind them to one of the following:

• an explicitly trusted Ed25519 signer;
• a bearer, OAuth, mTLS, or workload identity;
• a trusted reverse proxy identity;
• an authenticated NATS account and subject policy;
• a verified webhook signature and source mapping.

The runtime then freezes a trusted execution context. A connector receives that context and cannot replace it with values copied from action input.

Tenant and Credential Resolution

Tenant and credential mappings belong in a server-controlled directory or identity service. The standard daemon accepts a trusted identity file containing active, revisioned bindings. Bindings may include verified tenant membership, sanitized identity mapping, and an opaque credential handle.

Raw API keys, OAuth access tokens, and client secrets do not belong in an AIP envelope, manifest, identity file, receipt, or audit event. The connector or credential provider resolves an opaque handle at the final outbound boundary.

Delegated Authority

A delegated authority grant names the principal whose work is covered, the allowed scopes, an optional expiration, and an audit reason. Authorization must check the authenticated delegate, target principal, requested capability, scope, tenant, and expiration.

A generic *:any permission is not equivalent to a scoped grant. Prefer a grant such as “may read actions owned by principal X until time Y” over a global operator role.

Approval Authority

Approver identity is resolved independently from the action requester. Trusted authority membership may come from a principal binding, role, group, tenant policy, external approval system, or an active delegated approval grant.

The runtime must ignore role or group names asserted only by the decision payload. Separation-of-duties rules are evaluated against resolved identities, not display names.

Trust Domains and Federation

A trust domain owns principals, capabilities, resources, policy, and signer bindings. Cross-domain delegation carries a bounded hop history and an explicit scope. Each receiving gateway authenticates the immediate peer and applies its own policy; it does not inherit universal trust from the first sender.

Least-Privilege Checklist

• Authenticate before reading caller-controlled principal fields.
• Bind every operational query to principal, tenant, and scope.
• Keep credential material outside protocol objects.
• Use short-lived delegated grants with explicit target principals.
• Require separate identities for request, approval, and operation when policy calls for separation of duties.
• Redact regulated or restricted payloads before logging or delegation.
• Rotate signer and token bindings with a bounded overlap window.
• Treat development bearer tokens and --allow-insecure-development as loopback-only conveniences.

See Production Deployment for the runtime boundary and Approvals and Policy for authority evaluation.