Appearance
Access Control
Manifest holds no permission tables of its own. Every decision — who may design, publish, propose, review, or read — is made per request by Authlink, the platform's identity provider and policy decision point (PDP). Manifest's job is to enforce those decisions and their obligations, fail-closed.
Decisions
Users sign in through Authlink (OpenID Connect); agents present Authlink-issued task tokens. On each governed operation Manifest asks the PDP for a decision. A timeout or an unreachable PDP is a deny — availability never widens access.
Obligations
A PDP decision can carry obligations Manifest must honour for the decision to stand:
- Row filters — the caller sees only the instances the policy's filter admits. Filtered rows are simply absent; on direct lookups, a filtered instance answers not found, indistinguishable from a genuinely missing one.
- Property masking — masked properties are rendered as explicit redaction: the key remains, the value is null, and the response marks which properties were masked. Consumers see that something was withheld without seeing what — and a masked value never leaks through history, search, or audit renders.
- Required reason — some decisions demand the caller state why. REST callers supply the
X-Manifest-Reasonheader; the platform challenges when it's missing or too short, and the recorded reason joins the audit trail. - Audit — operations the policy flags are recorded with their full decision context.
On writes, an obligation the platform cannot enforce refuses the action outright — fail-closed, never best-effort.
One seam
All read surfaces — instance detail, lists, object sets, search, history, and the agent view — pass through a single read-governance seam, so an obligation enforced anywhere is enforced everywhere. The obligation contract is versioned documentation; consumers can rely on the redaction shape.
Always on: the gate and the vocabulary
Access control has no switch.
- The gate is unconditional. Every REST endpoint, MCP tool and execution checks its permission key with the PDP. No configuration turns this off.
- Manifest writes its own permission vocabulary. Every object- and action-type save and every publish converges into Authlink's catalog: the type's permission keys, its reader and admin roles, and the grant policies that make them authorize. This runs wherever Manifest's Authlink client credentials are configured. Without them, nothing converges and each design's Access Control status stays Pending.
- Grant operators before the first deploy. Because the gate enforces from the first request, an environment needs a
manifest:*wildcard grant for its operators in Authlink before it is first deployed. - Lockout is fixed in Authlink. Correct the grant in the Authlink portal; the PDP applies it immediately. There is no off-switch in Manifest.
Operators follow docs/runbooks/access-control-enablement.md when bringing up an environment.