Policies

A policy is a rule that decides whether a credential access is allowed. Every app.request() is evaluated against the relevant policies before the token is injected; if the policy denies, the call raises PolicyViolationError and the provider is never reached.

Note

Policies never grant access — they only narrow it. Access is default-deny (zero-trust): a credential is already gated by ownership (the principal must own the grant), scope (the key must carry the capability), and the grant’s validity (not expired or revoked). With no policy set, access still requires all three. A policy is an additional layer that can only further restrict — deny a request, limit it to certain times or IPs, or require human approval — never widen what’s allowed.

Policies sit between who can call (the principal on the grant) and what they’re allowed to call right now. The principal binding answers “is Alice’s grant?”; the policy answers “is now a valid time, from a valid place, within rate?”

Where a policy lives

Layer	Set by	Example
Grant policy	The operator or end user, at grant creation	TTL: this grant expires in 1 hour
App policy	The operator, in the developer portal	IP allowlist: only requests from 203.0.113.0/24
Provider policy	The operator	Time-of-day: only between 09:00–18:00 UTC
Agent policy	The operator, when provisioning a managed agent	Rate limit: 60 requests per minute

Policies compose. A request that satisfies the grant policy but violates the agent’s rate limit still fails.

What policies can express

• Time-of-day windows — business-hours-only access.
• IP allowlists — call only from named CIDRs.
• Group membership — restrict to members of an IDP group.
• Rate limits — cap per-grant or per-agent calls per minute.
• TTL — hard expiry on a grant.
• Approval requirements — route to a human-in-the-loop decision before executing.

Operators do not write policy files directly — the portal exposes a structured form per policy type, evaluated against a dedicated policy engine on every request.

Fail-closed

If a policy cannot be evaluated (the policy engine is unreachable, the inputs are malformed, the policy version drifted), the request is denied. No call is made; no token leaves the vault. The error surfaces as PolicyViolationError with the failure reason on policy_error.

This is the opposite of fail-open systems where a missing policy is treated as “no rule, allow.” Alter treats a missing policy evaluator as “no decision, deny.”

Audit

Every policy decision (allow, deny, or error — error meaning the policy gate itself failed to evaluate and the request was denied fail-closed) is recorded in the audit log with the policy name, the inputs evaluated, and the outcome. Denied calls never reach the provider but always appear in the audit trail — they are first-class evidence for compliance reviews.

What’s next

• Audit logs — where policy decisions are recorded.
• Add human-in-the-loop approvals — policy-driven approval flow.
• Security architecture — the policy engine in the larger picture.