← All experience

SIA Partners · Open-source agentic AI platform

Authority that narrows at every agent hop

Project lead, permission engine and identity provider

Jul 2026 - present

I lead the identity and authorization block of an open-source, on-premises-first agentic platform. The block must preserve the originating user's identity while preventing an agent from borrowing more authority than its own scope and clearance allow.

The security boundary

A user request can expand into several agents and tool calls. Each hop needs an identity linked to the initiating user, but delegation cannot become unrestricted impersonation. The platform also has a sovereignty constraint: every primary component must have a usable free self-hosted tier and remain replaceable.

My responsibility covers the block end to end: evaluation criteria, product benchmarks, the relationship-based authorization model, integration contracts, Kubernetes deployment, and guidance for the teams consuming it. The gateway, runtime, memory, observability, model serving, and studio have separate owners.

One evaluation method for both halves

The selection framework tested identity and authorization candidates against deployment, security, functional coverage, operations, integration, and cost. It also verified that every required capability existed in the free self-hosted edition. That requirement removed two leading candidates whose relevant features required enterprise tiers.

The outcome was a documented leaning toward Keycloak for identity and OpenFGA for authorization. Each decision records the condition that would reverse it. AuthZEN provides the policy decision contract so callers do not depend directly on OpenFGA's API.

The authorization model

The model treats both users and agents as principals. When an agent acts for a user, access is the intersection of their permissions. A C2 agent acting for a C4-cleared user still cannot read a C4 document, and an agent scoped to one project cannot inherit the user's access to another.

Clearance is encoded as relationships rather than a comparison in application code. Holding C3 implies C2 and C1, but not C4. Delegation is represented by one task-scoped relationship tuple, so revoking that tuple removes the borrowed authority without changing either principal's permanent role.

What is deployed

Keycloak 26.2 runs in production mode and OpenFGA uses an OpenID Connect protected API. Both run on the development Kubernetes cluster under Argo CD and persist state in CloudNativePG. An idempotent realm bootstrap and model-loading job make the configuration reproducible after a deployment.

Six design documents cover the two evaluations, recommendations, authorization model, and deployment usage. The usage guide gives other stream owners the current in-cluster endpoints, authentication path, request format, and known caveats.

The deployment evolved after state was lost

Both services first ran with ephemeral state. A pod restart removed the Keycloak realm, which then broke OpenFGA's OpenID Connect discovery. The first recovery mechanism made the realm bootstrap idempotent and reran it through an Argo CD PostSync job. Recovery became a normal synchronization rather than a manual repair.

The durable correction moved Keycloak and OpenFGA onto highly available PostgreSQL through CloudNativePG. This also exposed a cluster-specific constraint: the cluster had no default StorageClass, so an empty storage class left the database volume unbound and the pod unschedulable. The final deployment specifies that dependency rather than relying on a cluster default that does not exist.

The important work continues at the integration seams

The gateway needs an external authorizer over Envoy gRPC or HTTP, while OpenFGA does not expose that interface directly. The design therefore needs a small adapter from the gateway contract to AuthZEN. Naming and owning that adapter is part of the architecture cost, not an implementation detail to hide behind the product choice.

Auditability also crosses service boundaries. Token exchange and resource access need a shared trace identifier so an operator can reconstruct which agent accessed which resource on behalf of which user. Authorization logs must include the relationship path that produced the decision, not only an allow or deny result.

Current validation boundary

The block is deployed, but the wider platform integration is still in progress. The design still needs end-to-end load testing, validation of the linear C1 to C4 hierarchy, and a deliberate response when either the identity provider or authorization engine is unavailable.

• Keycloak 26.2
• OpenFGA
• AuthZEN
• OAuth 2.0
• OIDC
• DPoP
• mTLS
• CloudNativePG
• PostgreSQL
• Kubernetes
• Argo CD
• Helm