What did Keymate present at Java Day Istanbul 2026?

A 25-minute talk titled "Beyond the Gateway: Fine-Grained Authorization for AI Agents," followed by a live demo of one policy artifact evaluated across five scenarios and two social-engineering attempts, with an AI agent driving the runtime side through an MCP server.

What is open-sourced in the Keymate Authz Toolkit?

The toolkit (Apache-2.0, Java 17+) ships two Maven modules: authz-toolkit-core, the policy evaluation library, and authz-toolkit-cli, which provides the kmctl authz validate, simulate, and explain commands. The repository also contains the demo policy and scenarios used at Java Day.

Why publish this now?

The IAM ecosystem has moved fast on identity and protocol questions for AI agents, but condition-level authorization, deciding what an agent may reach with a given token, is still an open door. Recent public incidents involving broadly scoped tokens in agent hands made the gap concrete. Sharing the policy artifact, the engine semantics, and the design-time CLI as open source lets the community evaluate the approach against real workloads.

Where should I start: this post, Part 1, or Part 2?

Start here for context: what was presented, what is open source, and why it matters. Read Part 1 for the problem framing through the lens of current standards and a publicly reported incident. Read Part 2 for our approach in detail: declarative policy artifacts, a centralized decision engine, and a design-time CLI toolkit.

AI Agent Authorization: From Java Day Demo to Open Source Toolkit

Estimated read: 3-4 minutes

TL;DR

In April 2026 at Java Day Istanbul, we gave a 25-minute talk on fine-grained authorization for AI agents and walked through a live demo: one policy artifact, five scenarios, and two social-engineering attempts driven by an AI agent through an MCP server.
We have now open-sourced the design-time side of that work as the Keymate Authz Toolkit (Apache-2.0), available at github.com/Keymate-io/keymate-authz-toolkit. The exact policy and scenarios we ran on stage are in the repository.
The thesis behind the talk and the toolkit is one sentence: authentication tells us who the agent is; the real question is what data it can reach, under what conditions, and on whose behalf.
This post is the entry door to a deeper blog series. Part 1: Why AI Agents Need Fine-Grained Authorization frames the problem through current standards and a publicly reported incident. Part 2: How Keymate Enforces Fine-Grained Authorization for AI Agents walks through the policy artifact, the decision engine, and the design-time CLI, with the same policy semantics designed to carry into runtime enforcement.

What We Brought to the Stage

We first presented this work at Java Day Istanbul 2026, where we used a live demo to explore a practical question for AI agent systems: once an agent has a valid token, who decides what it can actually access? The talk was titled "Beyond the Gateway: Fine-Grained Authorization for AI Agents," delivered to an audience built around Java and platform engineers.

The talk was organized around one question:

Once an AI agent has obtained a valid token, how do we decide what data it may reach, under what conditions, and on whose behalf?

For many classic application flows, an API gateway plus authentication and route/scope checks can be enough for coarse access control. For autonomous agents that talk to LLMs, MCP servers, tools, and other agents in sequence, that surface leaves the harder question unanswered. The harder question is no longer "can this request pass" but "what may it reach, under what conditions, and on whose behalf." Answering it requires evaluating tenant, actor identity, trust level, request channel, resource ownership, and risk score together. None of these inputs fits naturally inside a route rule or a scope check.

We argued that the answer belongs in a declarative policy artifact, evaluated by a centralized decision engine, and verified at design time with policy semantics designed to carry into runtime enforcement.

The Demo: One Policy, Five Scenarios, One Agent

The live demo had a single policy at its center: an agent-invoice-read rule expressing under what conditions an invoice-agent may read an invoice. The condition combined seven inputs in a single expression: agent type, agent trust level, actor presence, request channel, tenant match against the resource, actor role, and current risk score.

We then ran two surfaces in sequence:

Design time. With kmctl authz, we validated the policy schema, simulated five scenarios (one GRANT and four DENY paths covering low trust, tenant mismatch, missing actor context, and high risk), and used explain to open the decision chain condition by condition for a denied case. (GRANT is the runtime result corresponding to a policy-level allow decision.)

Runtime. We placed an AI agent on the client side of the same flow, with an MCP server exposing two tools: get_agent_token (obtains a token from Keymate IdP, our Keycloak-based authority) and check_invoice_permission (calls the Access Gateway's check-permission endpoint). The agent translated natural-language intent into those two calls, and the decision was made outside the agent every time.

We also ran two social-engineering rounds. Within the demo's tool surface and credential boundary, the agent had no path to widen its own authority: enforcement remained in the policy layer, and the agent could only report the verdict.

The point of the demo was not the agent. It was that the authorization decision was deterministic, explainable, and designed around the same policy semantics across design time and runtime.

What's Open Source

The design-time side of the work is now available as the Keymate Authz Toolkit under Apache-2.0. The repository ships:

authz-toolkit-core, a Java 17+ library containing the rule matcher, condition evaluation, and why-denied trace logic. Embeddable as a Maven dependency in any JVM application.
authz-toolkit-cli, the kmctl authz binary built with Picocli. A self-contained fat JAR for developer machines and CI pipelines, exposing validate, simulate, and explain.
The Java Day demo artifacts, including the agent-invoice-policy.yaml policy and the agent-invoice-scenarios.json five-scenario simulation set, so anyone can reproduce the exact flow we ran on stage.

This is the part of the work that developers can pick up today, point at their own access patterns, and use to express, test, and explain authorization policies before deploying them.

Why Now

The identity, security, and governance ecosystems have moved fast on AI agents over the past year. Emerging drafts, published standards, and governance toolkits each address part of the picture: Transaction Tokens for Agents (IETF draft), Cross-App Access (XAA, in draft), RFC 9728 on Protected Resource Metadata (published), the AAuth draft, the OWASP LLM and Agentic Top 10 lists, and Microsoft's Agent Governance Toolkit. Together they cover how tokens are obtained, how identity propagates, how governance is set up, and how risks are mapped.

These are important steps. But they do not, on their own, answer "what data can this agent reach, under what conditions, on whose behalf," and recent public reports of broadly scoped tokens in agent hands have made the cost of that gap concrete.

That is the space the Java Day talk addressed and the space the open-source toolkit lives in. The combination we believe addresses it: declarative policy artifact + centralized evaluation + design-time test + policy semantics designed to carry into runtime.

Where the Series Picks Up

This post is the entry door. The first two deeper pieces in the series are:

📖 Part 1: Why AI Agents Need Fine-Grained Authorization. Why authentication alone is not enough, what the IAM ecosystem has built around the problem, and how a recent publicly reported incident illustrates the gap.
📖 Part 2: How Keymate Enforces Fine-Grained Authorization for AI Agents. The three building blocks (Access Rules, Access Rule Engine, kmctl authz), the runtime flow through Access Gateway, and how the same policy semantics are designed to carry from a developer's machine to production.

Beyond these two, we plan smaller deep-dives on Access Rules patterns, kmctl authz workflows, MCP integration, runtime enforcement, explainability, and a watchlist of the standards and drafts moving in this space.

If the toolkit interests you, the fastest way in is to clone the repo, run kmctl authz validate against the demo policy, and then write your own scenarios for an access pattern you actually care about. The design-time loop is intentionally short. Once it feels right, the same policy model is designed to carry into the runtime side without rewriting the rule.

We are continuing to ship, and we would rather hear "this is where it breaks for us" now than after the next release.