Agentic AI Security: Protecting Interactive Keycloak MCP App with OpenID AuthZEN Gateway for FGA

This article was originally published on LinkedIn.

Today, I am excited to announce a first look at the TwoGenIdentity AuthZEN MCP Gateway for our new Keycloak MCP app implementation. The focus of this work is demonstrating how to implement security standards to protect AI-driven interactions.

Following up on my previous articles, we have added support for the MCP App extension to our Keycloak MCP Server. This enables interactive and structured UI experiences for managing Keycloak IAM with an AI assistant. We also expose it through our AuthZEN MCP Gateway to provide standardized and decoupled authorization using an external AuthZEN-compliant PDP.

In the demo with Claude, the AI assistant interacts with the Keycloak MCP app to securely manage identities and authentication flows via the MCP Gateway where authorization policies are enforced in a standardized way. The authenticated user can list and view identities but is not authorized to delete them. Authentication flows are also exposed (easter egg for Keycloak users: beautiful flow visualizations).

There is a lot to unpack, but I would like to try to summarize the main points.

Table of contents

Security Is the Product

My focus - and the services I work on - are fundamentally about security. AI, MCP, and MCP Apps are accelerators, but:

Security remains the product, not a side effect.

This work is driven by concrete security requirements:

• Enforcing least privilege in dynamic AI workflows
• Separating policy decisions from execution
• Maintaining auditability and compliance as interactions become conversational and UI-driven
• Supporting multiple authorization models without locking into a single vendor or engine
• Implement open standards

This is why AuthZEN is central:

• It standardizes how Policy Enforcement Points (PEPs) talk to Policy Decision Points (PDPs)
• It allows security teams to govern authorization independently of application code
• It supports true policy-as-code governance across APIs, MCP servers, and MCP Apps

Open Security Standards Are Not Optional

The most important aspect of this work is not the demo itself.

It is that the entire approach is built on open security standards:

🟩 Baseline flow - Core Standard (green arrows), focused on OAuth 2.1 / 2.0 specs, the adopted security standards in the MCP space.

🟨 Enhanced security flow: OpenID AuthZEN specification to externalize and standardize authorization, starting with the communication between the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). Once authorization is standardized, you can adopt different authorization models such as ReBAC or PBAC in a consistent and interoperable way.

This ensures:

• Interoperability across tools and vendors
• No proprietary authorization silos
• The ability to evolve architectures without rewriting security logic

In an AI-driven world, closed security models do not scale.

What Changed with our AuthZEN MCP Gateway

MCP Apps unlock a new interaction model, but they also raise a critical security question:

How do we secure AI-driven interactions without vendor-locked security or authorization models?

The answer, for me, is standardization.

With the AuthZEN MCP Gateway:

• OAuth / JWT Security supported integration
• Act as standardized AuthZEN Policy Enforcement Points (PEPs)
• Authorization decisions are delegated to external, AuthZEN-compliant PDPs such as OpenFGA, Cerbos, etc
• Policies are evaluated dynamically using MCP context, along with authorization and authentication context

This is the key point:

Authorization logic is no longer embedded in MCP tools or AI workflows. It is externalized, standardized, and governed.

Therefore, you can enable the MCP security configuration as follows:

{ "pdp": { "host": "http://authzen-pdp:3593" }, "mcp": { "enforce_on": { "methods": ["tools/call"] } }, "subject": { "type": "user", "id": "claim::preferred_username", "properties": [ { "key": "roles", "claim": "realm_access.roles" }, { "key": "tenant", "claim": "organization" }, { "key": "acr", "claim": "acr" }, { "key": "amr", "claim": "amr" } ] }, "resource": { "type": "mcp", "id": "keycloak:iam" }, "action": { "name": "mcp::tool::name" } }

Using Dynamic JWT Context Extraction, the gateway then extracts relevant context from the OAuth access token, including the username (preferred_username), roles, tenant information, Authentication Context Class Reference ( acr ), and Authentication Methods References ( amr ).

Thanks to Dynamic MCP Request Mapping, in this example the gateway extracts the MCP tool name ( mcp::tool::name ), for example keycloak_delete_user. Authorization policies are enforced only on the tools/call MCP method.

These attributes are forwarded to the PDP in the resulting AuthZEN evaluation request. For example:

{ "subject": { "type": "identity", "id": "embesozzi", "properties": [ { "key": "roles", "claim": "admin" }, { "key": "tenant", "claim": "tenant-1" }, { "key": "acr", "claim": "inherence" }, { "key": "amr", "claim": "passkeys" } ] }, "resource": { "type": "mcp", "id": "keycloak:iam" }, "action": { "name": "keycloak_delete_user" } }

The AuthZEN PDP can then use this information directly in authorization policies. For example, you can enforce that only admin users authenticated with phishing-resistant authentication, such as an acr claim value of inherence and an amr claim value of passkeys, are allowed to delete users.

Finally, based on the AuthZEN evaluation response, the MCP gateway enforces the decision.

What Changed with the Keycloak MCP App

The interaction model fundamentally changes:

• The app exposes interactive, structured UIs directly inside AI conversations
• AI assistants move beyond scripts and text into real, guided workflows
• Users interact with capabilities, not dashboards

Imagine building custom UIs or help desk modules, forcing users to log in to a platform, or showcasing MCP for IAM commercial platforms using only plain-text interactions. That’s old school 🙂.

Check out the demo to see how this works across several use cases.

The “Bring Your Own” Era

When you combine MCP App with the AuthZEN MCP Gateway, you enter what I call the Bring Your Own era.

FROM:

• Log in to your IAM SaaS or IAM platform
• Hardcode authorization rules inside MCP servers or APIs

TO:

• Bring your AI assistant and interact through the Keycloak MCP App
• Bring your authorization policies (your AuthZEN PDP) and connect through the MCP Gateway

This enables:

• AI assistants as first-class enterprise clients
• MCP Apps delivering the right UI at the right moment
• Authorization enforced consistently, regardless of where the action originates

Security becomes portable, not embedded.

Why This Is More Than a Demo

This first look is intentionally focused on security and concrete architecture patterns, not features.

It demonstrates:

How to implement open security standard to protect AI-driven interactions

What’s Next

Future articles will explore:

• Describing multi-PEP architectures in greater detail within AI-driven workflows
• Combining RBAC and ReBAC using AuthZEN PEPs
• And yes - taking a little time to breathe as well:)

This article does not go into depth on all topics related to OIDC, OAuth, and passkeys (some of which I’ve covered in other articles). New topics will be covered in future releases. It’s also worth noting that both AuthZEN and the MCP app extension are still in early stages and offer significant room for further exploration.

If you care about AI security, IAM, and open standards, I’m always happy to exchange ideas. And if you’re interested in adding new and interesting use cases to the MCP app, feel free to reach out.