TMF Catalyst: Trusted Agentic AI for Access Management

Overview

In 2026 the TM Forum ran the Catalyst "Trusted Agentic AI for Access Management" under the reference C26.0.921. Participants were Vodafone Group, Deutsche Telekom AG, Celfocus, GIP Exyr GmbH and Tallence AG. The guiding question: how may an AI agent change access rights inside a telecommunications network without the agent itself becoming the thing you trust?

Tallence answered it with Digital Identity Management, the ODA component TMFC020, as the trust anchor of the demo: the place where every access decision is made, recorded and stays traceable. Alongside it came the Legal Agent, which turns legal text into policy proposals. I built the Tallence contribution as a one-person team, from architecture through Terraform and the Python Lambdas to two React applications and the agent itself. The result was shown at DTW 2026, where the Catalyst drew an interview in Mobile Europe and published statements from Vodafone and Deutsche Telekom.

Challenge

Telecommunications providers run identity and access management spread across many systems. Access decisions are fragmented over OSS, network and tooling, and every regulatory change reaches those systems as text rather than configuration. GDPR, the German Federal Data Protection Act, the Security Screening Act and the KRITIS Umbrella Act only become enforceable rules once somebody interprets them and enters them into a permissions system.

That is where the cost sits. Static RBAC does not follow a moving legal position, manual interpretation produces errors and delays, and what one system enforces the next one does not. The consequences are audit exposure, uncontrolled access to critical infrastructure, and a rate of change that holds new services back.

The harder problem of the Catalyst lay elsewhere. Attaching a language model to a permissions system is straightforward. The hard part is the assurance an operator needs to give its auditor: that an AI-proposed rule change stays deterministic, traceable and auditable even when the model is wrong or manipulated. An agent that decides access rights on its own is the opposite of a control point.

Role

I owned the whole Tallence contribution and filled three roles in parallel:

• Product Owner: use-case scoping with the partners, agreeing the expected decisions, demo script
• Architect: trust boundaries, Cedar schema, gateway separation, data residency and least privilege
• Full-Stack Developer: Terraform modules, Python Lambdas, two React SPAs, the agent and the pipeline

The analyst-facing Legal Agent was also how I came to understand every angle of the implementation. Whoever builds the surface that triggers a policy change has to know every contract underneath it: the token format, the role check, the idempotency of a rollback, the shape of the impact analysis. The agent served to validate the use cases and at the same time delivered the full functionality the demo needed.

Process

I modelled authorisation as data rather than as code. A Cedar schema in Amazon Verified Permissions describes the Operator and Customer entities with their attributes plus the two actions read and configure. A baseline policy grants network engineers access; two forbid policies created at runtime layer the regulatory restrictions on top. Authorisation logic therefore changes without a deployment, and the decision is made in a policy engine rather than in a prompt.

In front of the Lambdas I placed two independent AgentCore Gateways, reachable as managed MCP servers over Streamable HTTP with SigV4. The northbound gateway evaluates access, singly and in batches. The southbound gateway changes policies. Each has its own Lambda role, its own IAM consumers and its own tool schemas. Every decision writes an immutable record.

Keycloak on ECS Fargate with Aurora Serverless behind it supplies the identities. The tokens it issues carry the TMF672 operator attributes that Cedar evaluates as principal attributes: role, EU residency, clearance level and country. An audit frontend on CloudFront and S3 makes the decision history searchable.

The Legal Agent runs as a Strands agent on AgentCore Runtime, streaming over Server-Sent Events. Claude Sonnet 4.6 is reached exclusively through the EU inference profile. Legal grounding comes from a Bedrock Knowledge Base with S3 Vectors over four statutory texts, conversation state from AgentCore Memory. For the document path, an EventBridge rule on an S3 bucket starts a Step Functions machine: a diff hash against reprocessing, knowledge base ingestion, a dry-run impact analysis, then a waitForTaskToken halt with a 24-hour window until a human decides.

From document to policy: ingestion, analysis, human approval, application

The infrastructure lives entirely in Terraform, rolled out through GitLab CI/CD. Functional and security testing ran on KICS, ruff, bandit, semgrep, pytest and Hypothesis.

Decisions

The agent proposes, the policy engine decides. Cedar policies in Verified Permissions are the single authorisation authority. The model formulates proposals and justifications, but no prompt and no tool call can produce an access decision. That separation is the reason the demo gets to call itself trusted.

Human-in-the-loop as an architectural property, not a prompt instruction. Every change runs as a dry run first and then requires explicit confirmation. On top of that, the document workflow's service identity is barred from state-changing calls at two levels: in the agent, and independently in the role check of the permissions system. A circumvented prompt therefore still applies no policy.

Two gateways rather than one. The agent gets the southbound path only. It can change rules but cannot browse the operator and permission inventory. That matches the role of a legislation analyst, who sets requirements rather than inspecting users, and it confines the damage of a compromised agent to a path that changes nothing without approval.

Inference in the EU only. The agent accepts the EU inference profile alone and refuses to start on any other. A demo that demonstrates data protection compliance while carrying data out of the EU refutes itself.

The human identity travels with the request. The analyst's Keycloak token passes unchanged into the southbound call. The audit trail therefore names the acting person rather than a service account — the difference between a log and a piece of evidence.

Function URL streaming instead of API Gateway for chat. HTTP APIs could not stream responses until recently. The chat path therefore runs over a Lambda Function URL in streaming mode, same-origin behind CloudFront with Origin Access Control. The price was a single Node.js Lambda in an otherwise entirely Python repository.

Results

• Three regulatory use cases working end to end: baseline RBAC, data residency under GDPR and the Federal Data Protection Act, closed user group under the Security Screening Act and the KRITIS Umbrella Act
• Two independent AgentCore Gateways exposing five MCP tools, usable from any MCP-capable client
• Four statutory texts as the RAG corpus, with justifications carrying a verbatim passage and its source instead of freely worded legal advice
• Immutable audit trail for every decision, dry runs marked separately, a 24-hour approval window in the document workflow
• 100 percent of the infrastructure in Terraform, deployed via OIDC with no long-lived AWS credentials
• Fully serverless in eu-central-1, with no managed servers beyond the Fargate tasks of the identity provider
• Demonstrated as part of the Catalyst at DTW 2026

The most expensive debugging session of the project went on a version pointer. The AgentCore endpoint was bound to the runtime version that existed when it was created, and stayed there. Every deployment produced a new runtime version; the first one kept being served. The runtime stood at version 10 while the endpoint served version 1: every fix deployed, none of them live. The lesson travels beyond AgentCore. When a platform manages versions for you, check which one it is actually serving before you write the next fix.