# 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](../guides/production-deployment.md) for the runtime
boundary and [Approvals and Policy](approvals-and-policy.md) for authority
evaluation.