Access control

Access control in Premora is layered: the single front door enforces gateway-level policy, scopes govern what an identity can do, source ACLs govern what content it can see, and audit trails record what was done.

The single front door

premora-api-gateway is the only HTTP entry point. Web clients, the admin UI, the agent skill, and external API consumers never call internal microservices directly. This gives one place to enforce authentication, rate limits, request-size limits, and abuse controls.

Scopes

Identities (users and skill tokens) carry scopes mapped from their IdP groups or minted into a token. Scopes are filtered to a known catalog — an identity can never hold a scope Premora doesn’t recognize. For the agent skill specifically:

Scope	Grants
agent.read	Search, read wiki pages, lineage, graph, datasources, materialized views.
agent.write	The above plus governed queries, context packs, wiki promotions, clarifications.

Source ACLs (content visibility)

Beyond what an identity can do, Premora enforces what content it can see. Source permissions are captured as entitlement snapshots at ingest and enforced on every read across search, the wiki, the API, and the agent skill. Retrieval fails closed — if entitlement can’t be confirmed, content isn’t returned.

Delegated connections

Source connections that use per-user delegated credentials are default-denied. A pending grant lands in the admin approval queue, and the credential is only released after explicit admin approval — keeping user-scoped access auditable.

Break-glass

The local admin created at first run is permanent break-glass access. Elevated access is time-bounded and audited, so an emergency never becomes a standing privilege.

Audit trails

Admin actions, connector changes, query execution, report publication, and policy overrides are recorded. Combined with attributable skill tokens, this means every prompt, query, and output traces back to a user — the expectation regulated buyers have.