https://github.com/siddhant-k-code/agentic-authz
Fine-grained authorization for AI agents using OpenFGA.
https://github.com/siddhant-k-code/agentic-authz
agent agent-auth agent-authentication agent-security fine-grained-authorization openfga-client
Last synced: 26 days ago
JSON representation
Fine-grained authorization for AI agents using OpenFGA.
- Host: GitHub
- URL: https://github.com/siddhant-k-code/agentic-authz
- Owner: Siddhant-K-code
- License: mit
- Created: 2026-01-25T08:02:28.000Z (5 months ago)
- Default Branch: main
- Last Pushed: 2026-05-12T07:01:52.000Z (about 1 month ago)
- Last Synced: 2026-05-30T02:26:55.260Z (27 days ago)
- Topics: agent, agent-auth, agent-authentication, agent-security, fine-grained-authorization, openfga-client
- Language: TypeScript
- Homepage: https://youtu.be/m1_l13bC2O8
- Size: 125 KB
- Stars: 63
- Watchers: 1
- Forks: 4
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Agents: AGENTS.md
Awesome Lists containing this project
README
# Agentic AuthZ Demo
**Fine-grained authorization for AI agents using OpenFGA.**
AI agents are getting access to production systems - databases, APIs, file systems. But who decides what they can do? Traditional RBAC wasn't designed for autonomous agents that make decisions without human approval.
This demo shows how to implement **Relationship-Based Access Control (ReBAC)** for AI agents using OpenFGA, with three levels of authorization:
1. **Team Level** - Which teams can use which tool categories
2. **Project Level** - Which projects have access to which resources
3. **Operation Level** - Fine-grained control over destructive operations
## Quick Start
```bash
# Start services and seed data
make setup
# Run the demo
make demo
# Or use the interactive script
./scripts/demo.sh
```
## Why This Matters
| Problem | Solution |
|---------|----------|
| Agent has same permissions as user | Fine-grained, context-aware permissions |
| Prompt injection → data exfiltration | Blast radius contained by project scope |
| No audit trail for agent actions | Every authorization decision logged |
| "All or nothing" tool access | Operation-level restrictions |
## Architecture
```
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ AI Agent │────▶│ Gateway │────▶│ OpenFGA │
│ (Claude/GPT) │ │ (Go) │ │ (AuthZ) │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ MCP Tools │
│ (Mock/Real) │
└─────────────────┘
```
## Authorization Model
Three levels of access control:
### 1. Team Level
Teams are assigned to tool categories.
| Team | Code Tools | Communication | Data Tools | Infrastructure |
|------|------------|---------------|------------|----------------|
| Engineering | ✅ | ✅ | ✅ | ❌ |
| Marketing | ❌ | ✅ | ❌ | ❌ |
| DevOps | ✅ | ✅ | ✅ | ✅ |
### 2. Project Level
Projects have specific tool access.
| Project | GitHub | Slack | Postgres | Filesystem |
|---------|--------|-------|----------|------------|
| auth-service | ✅ | ✅ | ✅ | ❌ |
| landing-page | ❌ | ✅ | ❌ | ❌ |
| infrastructure | ✅ | ✅ | ✅ | ✅ |
### 3. Operation Level
Specific operations are restricted to certain roles.
| Operation | Allowed Roles |
|-----------|---------------|
| `github:delete_repo` | Team Leads only |
| `postgres:delete` | Team Leads only |
## Demo Scenarios
| # | Scenario | User | Tool | Expected |
|---|----------|------|------|----------|
| 1 | Engineering → GitHub | Alice (lead) | `github:create_pr` | ✅ Allowed |
| 2 | Marketing → GitHub | Bob (lead) | `github:create_pr` | ❌ Denied |
| 3 | auth-service → Postgres | Alice | `postgres:query` | ✅ Allowed |
| 4 | landing-page → Postgres | Bob | `postgres:query` | ❌ Denied |
| 5 | Member → delete_repo | Charlie | `github:delete_repo` | ❌ Denied |
| 6 | Lead → delete_repo | Alice | `github:delete_repo` | ✅ Allowed |
## Services
| Service | Port | Description |
|---------|------|-------------|
| Demo UI | 3002 | Interactive demo interface |
| Admin UI | 3001 | Permission management dashboard |
| OpenFGA Playground | 3000 | OpenFGA visual explorer |
| Gateway API | 9000 | Authorization gateway |
| OpenFGA API | 8080 | OpenFGA HTTP API |
## Development
```bash
# Install dependencies
make install-deps
# Start OpenFGA
make setup-openfga
# Run gateway in mock mode
make dev-gateway
# Run Demo UI
make dev-demo
# Run Admin UI
make dev-admin
```
## API Endpoints
### Check Authorization
```bash
curl -X POST http://localhost:9000/v1/tools/call \
-H "Content-Type: application/json" \
-d '{
"tool": "github",
"operation": "create_pr",
"params": {"title": "My PR"},
"context": {
"user": "alice",
"project": "auth-service",
"team": "engineering"
}
}'
```
### List Tools
```bash
curl http://localhost:9000/v1/tools
```
### View Audit Log
```bash
curl http://localhost:9000/v1/audit
```
### List Demo Scenarios
```bash
curl http://localhost:9000/v1/demo/scenarios
```
## Project Structure
```
agentic-authz/
├── gateway/ # Go authorization gateway
│ ├── cmd/gateway/ # Main entry point
│ └── internal/ # Internal packages
│ ├── authz/ # OpenFGA client
│ ├── config/ # Configuration
│ ├── handler/ # HTTP handlers
│ └── mcp/ # MCP proxy
├── demo-ui/ # Next.js demo interface
├── admin-ui/ # Next.js admin dashboard
├── openfga/ # Authorization model
│ ├── model.fga # FGA DSL model
│ ├── model.json # JSON model for API
│ └── tuples.json # Seed data
├── scripts/ # Demo scripts
├── docker-compose.yml # Service orchestration
└── Makefile # Build commands
```
## OpenFGA Model
The authorization model uses OpenFGA's DSL:
```fga
type tool
relations
define category: [tool_category]
define allowed_team: [team]
define can_use: member from allowed_team or can_use from category
type tool_operation
relations
define tool: [tool]
define allowed_role: [user]
define can_execute: allowed_role or can_use from tool
```
## Make Commands
```bash
make help # Show all commands
make setup # Full setup
make demo # Run all demo scenarios
make audit # View audit log
make tools # List available tools
make users # List demo users
make projects # List demo projects
make clean # Stop and clean up
```
## The Security Case for Agent Authorization
### The Problem
```
User: "Summarize our Q4 sales data"
Agent: *has database access*
Agent: SELECT * FROM users; DROP TABLE users;--
```
Without fine-grained authorization, a compromised or manipulated agent can:
- Access data outside its task scope
- Perform destructive operations
- Pivot between systems
- Exfiltrate sensitive information
### The Solution
```
User: "Summarize our Q4 sales data"
Agent: *requests database access*
Gateway: Check(user:alice, can_execute, tool_operation:postgres:query)
OpenFGA: ✅ ALLOWED (project:sales-dashboard has postgres access)
Agent: SELECT SUM(revenue) FROM sales WHERE quarter='Q4'
```
With this architecture:
- Every tool call is authorized
- Permissions are scoped to project context
- Destructive operations require elevated privileges
- All decisions are audited
## Real-World Use Case: Confidential AI Platforms
When AI coding agents work on security-critical codebases, the blast radius of a compromised or misdirected agent is much larger than in a typical project. This pattern applies directly to confidential computing stacks where certain components must never be touched by an agent.
**Example: Confidential AI inference platform (Intel TDX)**
A typical confidential AI stack has components where agent write access would be catastrophic:
| Component | Why it matters |
|-----------|---------------|
| `cvm/attestation-service/` | TDX quote generation and EKM validation logic |
| `cvm/auth-service/` | Bearer token auth and HMAC comparison |
| `cvm/cert-manager/` | TLS cert and EKM shared secret |
A developer running a frontend review agent should have no access to these components. With agentic-authz, this is expressed as the absence of tuples — no tuple written means no access, full stop.
```bash
# Grant the frontend review agent access to the frontend only
fga tuple write \
'{"object":"repo:my-project/frontend","relation":"reader","user":"agent:frontend-review-agent"}'
# No tuples written for attestation-service, auth-service, cert-manager.
# The agent cannot read or write those components regardless of what it "decides."
# Verify
fga query check --user agent:frontend-review-agent \
--relation reader --object repo:my-project/attestation-service
# { "allowed": false }
```
**Connecting attestation identity to authorization**
For platforms using attested TLS, the TEE's measurement (e.g. `app_compose_hash` from a TDX attestation report) can serve as the identity anchor in OpenFGA tuples:
```python
# After verifying the TEE attestation, extract the identity
tee_identity = report.tdx.app_compose_hash # deterministic per deployment
allowed = await fga.check(
user=f"tee:{tee_identity}",
relation="can_invoke",
object="service:inference-endpoint"
)
```
This gives confidential AI platforms a full authorization layer on top of their existing attestation stack: the aTLS layer handles authentication (who is connecting), OpenFGA handles authorization (what they can do).
---
## Resources
- [OpenFGA Documentation](https://openfga.dev/docs)
- [OpenFGA Playground](https://play.fga.dev)
- [Securing Agentic AI (Blog Post)](https://dev.to/siddhantkcode/securing-agentic-ai-authorization-patterns-for-autonomous-systems-3ajo)
## Author
Built by **Siddhant Khare** - OpenFGA Core Maintainer
- X: [@siddhant_K_code](https://x.com/siddhant_K_code)
- GitHub: [@Siddhant-K-code](https://github.com/Siddhant-K-code)
- LinkedIn: [Siddhant Khare](https://linkedin.com/in/siddhantkhare24)
*Helping teams implement secure AI agent architectures.*
## License
MIT