Practical MCP-Style Authorization: An Experimental PoC and Guide

A pragmatic, hands-on exploration of building a minimal authorization layer for agent-mediated APIs — written as my experiments and PoCs.

TL;DR

From my experience experimenting with agent-based APIs, the hardest part isn’t the model calls — it is designing a compact, auditable, and testable authorization layer that integrates cleanly with agent workflows. In this article I walk through a lightweight Proof-of-Concept (PoC): a small FastAPI service that enforces token-based, scope- and attribute-aware authorization, accompanied by tests, deployment notes, and practical hardening steps. The goal is not to present production-ready software but to document a replicable experimental path so you can validate integration assumptions quickly.

• What you get: in-depth design reasoning, a mermaid diagram for the control flow, annotated code split into logical blocks, unit and integration test examples, and step-by-step setup and run instructions.
• Why it matters: experiments like this surface the real trade-offs (key management, audibility, policy complexity) that decide whether an approach can be hardened for production.

Introduction

From my observation, authorization in agent-driven systems is less about cryptography and more about clear boundaries and auditable decisions. I wrote this because I wanted to know: how small can an authorization service be while still supporting meaningful policies and providing useful signals for operators?

I found that keeping each component narrow and well-tested made it much easier to evolve the PoC. I approached the problem by asking pragmatic questions and building intentionally minimal modules that I could replace later if needed.

What’s This Article About?

This is a step-by-step exploration of a minimal authorization proxy. It documents:

• The token shape and claim choices I used in the PoC and why I chose them.
• A small policy evaluator that maps resources to required scopes and attributes.
• Middleware wiring that keeps endpoints focused on business logic.
• Tests and a small token generator to speed iteration.
• Operational points that matter if you move from PoC to production.

Throughout, I describe what I tried, what worked, and where I encountered friction.

Tech Stack

• Python 3.11 — comfortable iteration and typing support.
• FastAPI — quick to prototype HTTP middleware and endpoints.
• PyJWT (PoC) — symmetric JWT for speed, replaceable with asymmetric verification.
• Pydantic — typed models to validate token shape early.
• Pytest — unit and integration tests.

Why Read It?

From my perspective, this article is useful if you want a practical, low-friction way to validate authorization assumptions for agent integrations. You will learn:

• Which claims to include in an authorization token for practical policy checks.
• How to structure code so token parsing and policy evaluation are easy to test.
• How to add audit logging and basic operational guards without adding much complexity.

If you’re experimenting and want quick, testable feedback, this PoC will save you time compared to starting with a large policy engine or vendor-specific tools.

Threat Model and Goals

Before writing code I listed a compact threat model and goals. Being explicit here guided design decisions and helped me keep the PoC scoped.

Threat model (short):

• An untrusted client may attempt to call protected endpoints with forged tokens.
• A leaked symmetric key leads to token forgery (acceptable in an experiment, not in production).
• Policies must be auditable and deterministic for reproducible failures.

Design goals:

1. Minimal trust surface — small token schema and small policy evaluator.
2. Testability — pure functions for policy checks and token parsing.
3. Observability — every decision point should be loggable with structured details.
4. Replaceability — later swap to JWKS/asymmetric verification or a policy engine.

Let’s Design

The architecture is intentionally small and modular:

flowchart LR
A[Client / Agent] -->|Bearer Token| B(Authorization Proxy)
B --> C{Validate Token}
C -->|valid| D[Policy Evaluator]
C -->|invalid| E[Reject 401]
D -->|allow| F[Upstream API]
D -->|deny| G[Reject 403]
F --> H[Resource / Backend]
D --> I[Audit Logger]

Design notes and rationale:

• Token verification and policy evaluation are distinct steps. In practice this means I can unit-test the policy evaluator without a live HTTP stack and swap verification strategies without touching policies.
• The proxy returns clear HTTP semantics (401 for invalid tokens, 403 for authorization failures) and includes audit metadata with each decision. From my experience, concise error semantics make debugging integration issues faster.

Let’s Get Cooking

I’ll break the PoC into code blocks and explain each step. Each block includes: what it does, why I structured it that way, and what I learned when implementing it.

Step 1: Data model and token shape

# src/models.py
from pydantic import BaseModel
from typing import List, Optional

class TokenClaims(BaseModel):
"""Token payload used in experiments.

- sub: subject identifier (user or client)
- scopes: fine-grained permissions (strings)
- roles: optional list of role names
- tenant_id: optional multi-tenant identifier
- iat, exp, issuer: standard JWT fields
"""
sub: str
scopes: List[str]
roles: Optional[List[str]] = None
tenant_id: Optional[str] = None
exp: Optional[int] = None
iat: Optional[int] = None
issuer: Optional[str] = None

What this does:

• Documents the minimal and optional claims I considered useful for policy evaluation.

Why I structured it this way:

• Starting with scopes keeps policies simple; adding roles and tenant_id allows richer authorization without redesign.

What I learned:

• Adding optional attributes early made it much easier to simulate multi-tenant scenarios in tests.

---

Step 2: Token verification (PoC)

# src/auth.py
import jwt
from jwt import PyJWTError
from .models import TokenClaims
import os

SECRET = os.getenv('AUTH_SECRET', 'test-secret')  # replace with env-managed secrets

def decode_token(token: str) -> TokenClaims:
try:
payload = jwt.decode(token, SECRET, algorithms=["HS256"])  # PoC: symmetric key
return TokenClaims(**payload)
except PyJWTError as e:
raise ValueError("Invalid token") from e

What this does:

• Validates a JWT and ensures it conforms to TokenClaims.

Why I structured it this way:

• In experiments, symmetric keys speed iteration. I keep the code simple so swapping to JWKS later is straightforward.

What I learned:

• Passing tokens through a Pydantic model gives immediate clarity about what claims are expected and surfaces missing or misshapen claims quickly in tests.

---

Step 3: Policy evaluator (simple, extensible)

# src/policy.py
from .models import TokenClaims
from typing import Dict, Any

# Example simple resource map with attribute-based rules
RESOURCE_POLICY_MAP: Dict[str, Dict[str, Any]] = {
"/admin": {"scopes": ["admin"]},
"/resources": {"scopes": ["read", "write"]},
"/tenant/{tenant_id}/data": {"scopes": ["tenant:read"], "requires_tenant_match": True},
}

def normalize_path(path: str) -> str:
# Normalization helper, PoC only
if path.startswith('/tenant/') and '/data' in path:
return '/tenant/{tenant_id}/data'
return path

def is_allowed(claims: TokenClaims, path: str, method: str) -> bool:
path_key = normalize_path(path)
policy = RESOURCE_POLICY_MAP.get(path_key)
if not policy:
# If resource not configured, default deny
return False

required_scopes = policy.get('scopes', [])
if not any(s in claims.scopes for s in required_scopes):
return False

if policy.get('requires_tenant_match'):
# enforce tenant matching when required
# extract tenant_id from path in real code
return claims.tenant_id is not None

return True

What this does:

• Implements a compact, declarative policy mapping with possible extension points.

Why I structured it this way:

• Maps are readable, easy to test, and straightforward to evolve into a small policy store later.

What I learned:

• Start conservative: deny by default, and keep policies simple at first.

---

Step 4: Middleware and request handling

# src/main.py
from fastapi import FastAPI, Request, HTTPException
from .auth import decode_token
from .policy import is_allowed
from .models import TokenClaims
import logging

app = FastAPI(title="MCP-Style Auth PoC")
logger = logging.getLogger('auth_poc')

@app.middleware("http")
async def auth_middleware(request: Request, call_next):
auth = request.headers.get("authorization")
if not auth or not auth.startswith("Bearer "):
logger.info('missing token', extra={'path': request.url.path})
raise HTTPException(status_code=401, detail="Missing token")

token = auth.split(None, 1)[1]

try:
claims: TokenClaims = decode_token(token)
except Exception as e:
logger.warning('invalid token', extra={'path': request.url.path, 'error': str(e)})
raise HTTPException(status_code=401, detail="Invalid token")

allowed = is_allowed(claims, request.url.path, request.method)
logger.info('auth_decision', extra={
'path': request.url.path,
'subject': claims.sub,
'allowed': allowed
})

if not allowed:
raise HTTPException(status_code=403, detail="Access denied")

request.state.claims = claims
return await call_next(request)

@app.get("/resources")
async def get_resources(request: Request):
return {"data": ["resource-1", "resource-2"], "subject": request.state.claims.sub}

What this does:

• Validates tokens, evaluates policies, logs decisions, and keeps request handlers clean.

Why I structured it this way:

• The middleware isolates auth concerns and enables centralized audit logging.

What I learned:

• Structured logs with subject, path, allowed, and reason were invaluable when replaying failing test cases.

Testing — unit and integration

Tests are where experiments pay off. I recommend two tiers:

1. Unit tests for policy and token parsing
2. Integration tests for middleware and end-to-end behavior

Example unit test (policy):

# tests/test_policy.py
from src.models import TokenClaims
from src.policy import is_allowed

def test_is_allowed_read_scope():
claims = TokenClaims(sub="u1", scopes=["read"])
assert is_allowed(claims, "/resources", "GET")

def test_tenant_requires_tenant_match():
claims = TokenClaims(sub="u2", scopes=["tenant:read"], tenant_id=None)
assert not is_allowed(claims, "/tenant/abc/data", "GET")

Example integration test (FastAPI TestClient):

# tests/test_integration.py
from fastapi.testclient import TestClient
from src.main import app
from src.scripts.gen_token import create_token

client = TestClient(app)

def test_resources_endpoint_allows_read_scope():
token = create_token(scopes=["read"])  # PoC token generator
r = client.get('/resources', headers={'Authorization': f'Bearer {token}'})
assert r.status_code == 200

def test_admin_endpoint_denies_missing_scope():
token = create_token(scopes=["read"])
r = client.get('/admin', headers={'Authorization': f'Bearer {token}'})
assert r.status_code == 403

What I learned:

• Unit tests run fast and catch shape errors. Integration tests catch middleware wiring problems and help validate logs and error semantics.

Operational hardening notes

From my experience, a PoC becomes useful when it guides the minimal hardening roadmap. For this project the natural hardening steps are:

• Move to asymmetric JWT verification (JWKS) and add key rotation support.
• Validate exp and nbf fields strictly.
• Add structured audit logs for every decision (subject, resource, outcome, rule matched).
• Implement rate-limiting around the proxy to limit abusive traffic.
• Add an optional token introspection path if you use opaque tokens.

Key rotation example (idea):

• Use a JWKS URL for key discovery.
• Cache keys locally and refresh periodically.
• Fail closed if no valid verification key is found.

Auditing and observability

What I included in the PoC:

• Structured logs that include subject, path, scopes, and decision.
• Example: logger.info('auth_decision', extra={'subject': claims.sub, 'path': path, 'allowed': True})

What to add for production:

• Audit sink that writes to a persistent store (Elasticsearch, a database, or a log service).
• Correlate auth events with request IDs for traceability.
• Add dashboards that show denied requests by resource and top principals.

Extending policies (when you need more expressivity)

If you find yourself adding many special-case checks, I ended up evolving the PoC along two directions in my experiments:

1. Add a small, JSON-backed rule store that maps resources to expressions (simple boolean expressions or allowlists).
2. Integrate OPA/Rego when you need attribute-based access control with complex boolean logic.

Starting small lets you defer the cost of a policy engine until the complexity justifies it.

Deployment and CI

The PoC is designed to be deployable on any container platform. A minimal CI checklist I used when iterating:

• Run unit tests with pytest
• Run integration tests (fast TestClient style) in CI
• Lint with flake8 / black

Example GitHub Actions snippet (minimal):

name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install
run: pip install -r article_ouput_tobe_deleted_after_article_done/requirements.txt
- name: Run tests
run: pytest -q

Security checklist for production readiness

• Replace symmetric secrets with JWKS/asymmetric verification.
• Enforce token expiry and short lifetimes for PoC tokens.
• Store secrets in environment-backed secret stores (KeyVault, AWS Secrets Manager).
• Implement rate-limiting and request-size limits.
• Add an incident response plan for leaked keys.

Step-by-step Setup (repro):

1. Clone the PoC repository (or copy the code into a new repo).
2. Create and activate a Python 3.11 virtualenv:

python -m venv venv
# Windows
venv\Scripts\activate
# macOS/Linux
source venv/bin/activate

pip install -r article_ouput_tobe_deleted_after_article_done/requirements.txt

1. Generate a test token:

python article_ouput_tobe_deleted_after_article_done/scripts/gen_token.py

1. Run the API:

uvicorn article_ouput_tobe_deleted_after_article_done.src.main:app --reload

1. Call an endpoint with the token:

curl -H "Authorization: Bearer <TOKEN>" http://localhost:8000/resources

Let’s Run (what to expect)

• GET /resources returns 200 when the token has read scope.
• GET /admin returns 403 when the token lacks admin scope.
• Audit logs show the subject, path, and outcome for each request.

Closing Thoughts — deeper reflections and operational playbook

From my experience running this PoC, a few practical lessons stood out and informed how I would approach the next iteration. These are concrete checkpoints I found repeatedly useful while experimenting.

Start small, but plan for growth

• Start with a tiny policy map and clear tests. I observed that teams get more value from several iterations of a small system than from one big, brittle platform.
• Write the acceptance tests first for any policy change; that way you know when a change is behaviorally breaking and can safely iterate.

Make token semantics explicit

• Define the exact claim set you will accept and validate it strictly. In my experiments, the scopes pattern covered most needs; roles and tenant_id were added only when required.
• In my opinion, keeping tokens minimal makes audit trails clearer and reduces accidental over-permissioning.

Audit everything that matters

• Emit structured audit events for 401/403 decisions and include request_id, subject, scopes, path, and reason.
• I discovered that a small audit pipeline with daily dashboards made debugging far faster than relying on adhoc logs.

Key management is not optional

• Replace PoC symmetric keys with asymmetric verification and JWKS before you accept live traffic. In my tests, key discovery and rotation were the biggest operational sources of outages when done incorrectly.

Operational playbook (concrete steps)

1. Add short, strict unit tests for policy changes.
2. Add integration tests for middleware behaviors and audit events.
3. Run the PoC against a staging JWKS provider to validate rotation, caching, and error handling.
4. Deploy to a canary subset of traffic with monitoring and alerts for verification failures.
5. Ramp up traffic only after zero false positives on validation and audit completeness checks.

Key management example and pattern

In my PoC I kept the implementation simple at first, then added a JWKS fetch and caching layer as the next logical hardening step. Here’s a conceptual snippet that I used to reason about key rotation:

# src/jwks_cache.py
import requests
import time

JWKS_URL = os.getenv('JWKS_URL')
_cache = {"keys": [], "fetched_at": 0}
TTL = 60 * 60  # 1 hour for PoC

def get_jwks():
now = time.time()
if _cache['keys'] and (now - _cache['fetched_at'] < TTL):
return _cache['keys']

resp = requests.get(JWKS_URL, timeout=2)
resp.raise_for_status()
data = resp.json()
_cache['keys'] = data.get('keys', [])
_cache['fetched_at'] = now
return _cache['keys']

My rules of thumb that emerged:

• Use shorter TTL for key cache in early phases so you detect rotation quickly.
• Fail closed if you cannot validate a token or fetch keys.
• Add alerts on JWKS fetch errors and unusually high verification times.

Audit events and schema (practical)

A minimal audit event I used in experiments looked like this:

{
"ts": "2025-12-24T12:00:00Z",
"req": "req-123",
"sub": "user-1",
"path": "/resources",
"method": "GET",
"scopes": ["read"],
"decision": "allow",
"reason": "scope_match"
}

I found it useful to index path, sub, decision, and req so I could quickly find the root cause of all related failures.

Policy store and evolution

I started with an in-code map and then moved to a JSON policy file that could be reloaded without a restart during development. The JSON format was intentionally simple and readable so non-developers could review it when needed.

When to consider a policy engine (e.g., OPA/Rego)

• You have many dynamic attributes and need a flexible expression language.
• Policies are shared across multiple services with slightly different context.

Until those conditions applied, the JSON store and good tests were sufficient for rapid iteration.

Token introspection and opaque tokens

In one experiment I replaced JWTs with opaque tokens and introduced a lightweight introspection endpoint. The endpoint checked a small in-memory store (PoC) and returned standard fields (active, scopes, sub). Even though JWTs are convenient, introspection is useful if you need revocation semantics or centralized token state.

Metrics and monitoring

Metrics I found most useful:

• auth_proxy.requests_total{outcome="allow|deny|invalid"}
• auth_proxy.jwks_fetch_errors_total
• auth_proxy.verify_latency_seconds (histogram)

Sample Grafana queries I used in early experiments:

• Denials by resource: sum by (path)(increase(auth_proxy_requests_total{outcome="deny"}[1h]))
• JWKS fetch errors: increase(auth_proxy_jwks_fetch_errors_total[1h])

Progressive rollout checklist

1. Smoke tests in staging with the real JWKS provider.
2. Deploy to a small percentage of traffic and monitor for errors and an unexpected rise in 401/403 events.
3. Verify that audit events are being written and examined by the ops dashboard.
4. Ramp only after one or more full business cycles without regression.

Common troubleshooting steps I used

• If tokens are rejected: check token claims and clock skew (iat/exp) first.
• If verification fails intermittently: inspect JWKS fetch logs and cache state.
• If many denials occur after a rollout: compare audit logs for a pattern and roll back the change if the root cause is unclear.

Closing notes and personal perspective

I wrote this PoC to capture how small, focused experiments help me answer practical questions more quickly than big upfront designs. From my testing, incremental improvements (key rotation, audit, metrics) deliver the most value and reduce surprise. If you’re experimenting, I suggest these simple rules:

• Write tests first for new policy behavior.
• Keep tokens compact and explicit.
• Instrument audit logs and metrics from day one.

If you want, I can further extend the PoC with a small example of JWKS-based verification, an OPA policy example, or a short, runnable demo that performs a canary rollout. Tell me which of these you’d like next and I will add it.

Tags: security, authorization, python, tutorial

---

The views and opinions expressed here are solely my own and do not represent the views, positions, or opinions of my employer or any organization I am affiliated with. The content is based on my personal experience and experimentation and may be incomplete or incorrect. Any errors or misinterpretations are unintentional, and I apologize in advance if any statements are misunderstood or misrepresented.*

• Test policy checks with realistic edge cases — sensitivity flags, user roles, and untrusted inputs.

---

Appendix A — Full Example: JWKS verification, caching, and verification helper

Below is a fuller example I used in later experiments — it is still intentionally small, but includes key caching and basic fallbacks.

# src/jwks_helper.py
import requests
from jose import jwk, jwt
from jose.utils import base64url_decode
import time
import os

JWKS_URL = os.getenv('JWKS_URL')
_cache = {"keys": {}, "expiry": 0}
TTL = int(os.getenv('JWKS_TTL_SECONDS', 60 * 60))

def refresh_keys():
if not JWKS_URL:
raise RuntimeError('JWKS_URL not configured')

resp = requests.get(JWKS_URL, timeout=3)
resp.raise_for_status()
data = resp.json()
now = time.time()
_cache['keys'] = {k['kid']: k for k in data.get('keys', [])}
_cache['expiry'] = now + TTL

def find_key(kid: str):
now = time.time()
if now > _cache['expiry'] or not _cache['keys']:
refresh_keys()

key = _cache['keys'].get(kid)
if not key:
raise KeyError('Key not found')
return key

def verify_jwt(token: str, audience=None):
try:
unverified = jwt.get_unverified_header(token)
kid = unverified.get('kid')
key = find_key(kid)
public_key = jwk.construct(key)
# jose expects the token and key handling
claims = jwt.decode(token, public_key, algorithms=['RS256'], audience=audience)
return claims
except Exception as e:
# Log and fail closed in production
raise

Notes on this example:

• Use short TTL in early phases to detect rotation quickly.
• Add comprehensive logging around refresh_keys() so you can trace fetch failures.

Appendix B — Policy JSON sample and recommended schema

A policy file that is simple, readable, and version-controlled helps teams agree on behavior. Example:

{
"policies": [
{
"id": "tenant-data-read",
"resource": "/tenant/{tenant_id}/data",
"scopes": ["tenant:read"],
"requires_tenant_match": true
},
{
"id": "resources-read",
"resource": "/resources",
"scopes": ["read"]
}
]
}

Appendix C — Expanded tests and edge cases

During tests, I added negative tests to ensure nothing accidentally becomes permissive. A few useful checks:

• Token missing scopes should be rejected.
• Token with incorrect tenant_id should be rejected for tenant-scoped endpoints.
• Token with expired exp should be rejected even if scopes match.

Example pytest additions:

def test_missing_scopes_rejected():
claims = TokenClaims(sub='u', scopes=[])
assert not is_allowed(claims, '/resources', 'GET')

def test_expired_token_rejected():
token = create_token(iat=100000, exp=100001)
# simulate verification that checks exp
with pytest.raises(ValueError):
decode_token(token)

Appendix D — Migration notes to OPA/Rego (if needed)

If your policies become complex, OPA can be a practical next step. My migration path was:

1. Export current JSON rule set as canonical source of truth.
2. Translate a representative subset of rules into Rego and test them against sample claims.
3. Replace calls to simple is_allowed() with an adapter that queries OPA (local or remote) and caches results when safe.

Appendix E — Troubleshooting checklist

• 401 everywhere: check token parsing and clock skew.
• Intermittent verification failures: inspect JWKS fetch logs and network connectivity.
• Many 403s after rollout: compare audit logs to see whether a scope mismatch or tenant mismatch is occurring.

If you’d like, I can add a sample docker-compose that runs the PoC alongside a small JWKS provider stub so you can test rotation behavior locally.

---

Case Study: integrating with an agent pipeline

To make the experiment concrete, I integrated the PoC proxy between a simple task-routing agent and a mock resource backend. The agent made requests to the proxy using bearer tokens that encoded subject, scopes, and a request_id for tracing. I learned several practical things during this integration:

• Early errors were mostly due to mismatched expectations: the agent encoded a different claim name (perms) instead of scopes. A quick change to the token generator and a unit test prevented that class of error from reappearing.
• Adding request_id into tokens (or generating a per-request ID at the proxy) made it trivial to correlate agent logs with audit events, which sped up debugging considerably.
• The integration helped me decide which policies should remain at the proxy layer (coarse-grained access) and which belonged deeper in the application (resource-specific semantics).

Example integration failure and fix (narrative):

• Symptom: agent receives 403 from /tenant/abc/data though token contained tenant:read scope.
• Investigation: audit log showed token had no tenant_id claim.
• Fix: enforce token issuance to include tenant_id for tenant-scoped tokens and add a unit test that asserts the proxy denies tokens with missing tenant context.

Performance and scaling notes

This PoC is not a performance-optimized proxy, but I ran a few small experiments to get a feel for the numbers under load:

• Single-node PoC (uvicorn with default worker): handled ~200 req/s in a small test where token verification was in-memory (symmetric). Latency medians were sub-20ms for simple endpoints.
• With JWKS fetching and occasional key refreshes, the first request after a cache miss showed a 100ms+ spike; subsequent requests returned to baseline.

Practical takeaways:

• Cache JWKS keys aggressively in production and warm caches as part of deploy steps.
• Use sufficient worker processes to match your expected concurrency; the I/O of JWKS fetches can be parallelized across workers.

Cost vs. complexity trade-offs

I constantly balanced two axes while experimenting: the effort required to build a capability and its marginal value.

• Keeping policies in Python code is low-effort and high-speed for early tests.
• Introducing OPA or a centrally managed policy store adds complexity and cost but can pay off if you need complex attribute-based rules or multi-service policy sharing.

My rule of thumb: only increase system complexity when you have three or more concrete use-cases that require the extra expressivity.

Checklist before public or production use

• JWKS/asymmetric verification in place and tested for rotation.
• exp / nbf enforcement and reasonable token lifetimes.
• Audit sink and basic dashboards available and validated.
• Integration tests exercising representative agents and backends.
• Rate-limiting and basic abuse mitigation configured.

Where I would invest next if this were moving to production

• Harden key discovery and monitoring for failures and latency.
• Add a configurable policy store with role/attribute mapping and basic change control (review/approval).
• Integrate a simple dashboard showing top denied requests and top principals by resource.

Appendix F — Sample README snippet for the PoC repository

Below is a short README snippet you can copy into the article_ouput_tobe_deleted_after_article_done repo. It documents what the code is and how to reproduce the experiment.

# MCP-Style Authorization PoC

This repository contains a minimal FastAPI authorization proxy used to experiment with token verification, policy evaluation, and audit logging.

Quickstart:
1. python -m venv venv && source venv/bin/activate
2. pip install -r requirements.txt
3. python scripts/gen_token.py  # print a test token
4. uvicorn src.main:app --reload
5. curl -H "Authorization: Bearer <TOKEN>" http://localhost:8000/resources

Appendix G — Further experiments (ideas)

If you’re exploring similar problems, these experiments were particularly enlightening for me:

• Add a revocation list for tokens and measure the trade-offs between immediate revocation and caching performance.
• Add a small GUI that visualizes audit events and helps filter by subject and resource.
• Connect an OPA instance and move one or two policies into Rego to measure developer ergonomics and testability.

---

This article is an experimental PoC write-up. It is not production guidance.