Agentic Identity Graph

A portfolio project that demonstrates graph-based identity resolution and runtime authorization for AI agents.

The project models how an enterprise AI agent should safely act on behalf of a user across tools, APIs, connectors, workloads, scopes, policies, and data boundaries.

Why this project exists

Modern AI agents do more than generate text. They call tools, invoke APIs, retrieve enterprise data, update systems, and perform multi-step workflows. That creates a new security problem:

Which identity is the agent using, what authority does it have, and should this tool call be allowed right now?

This project answers that question using an identity graph plus runtime authorization checks.

Core ideas

• Resolve effective identity across user, org, data-space, agent, connector, workload, delegated scopes, and session context.
• Authorize agent-to-tool calls using graph relationships, required scopes, tenant boundaries, and risk signals.
• Detect confused-deputy and prompt-injection-style risks before an agent performs sensitive actions.
• Return explainable authorization decisions with graph paths and denial reasons.

Architecture

flowchart LR
    U[User] -->|member_of| O[Org]
    U -->|has_scope| S1[crm.read]
    U -->|has_scope| S2[crm.write]
    U -->|can_invoke| A[AI Agent]
    A -->|runs_as| W[Workload Identity]
    A -->|allowed_tool| T[Tool]
    T -->|uses| C[Connector]
    C -->|requires_scope| S1
    C -->|requires_scope| S2
    T -->|accesses| D[Data Space]
    P[Policy] -->|applies_to| T

    R[Runtime Request] --> G[Identity Graph Resolver]
    G --> E[Policy Evaluation]
    E -->|allow/deny + reasons| DEC[Authorization Decision]

Loading

What it demonstrates

Area	Demonstrated capability
Agentic identity	User, agent, workload, connector, and delegated scope modeling
Graph-based identity resolution	Relationship traversal and effective identity construction
Runtime authorization	Tool-call decisions based on graph facts and request context
Policy enforcement	Least privilege, token freshness, tenant isolation, and sensitive action gating
Security analysis	Prompt injection, confused deputy, stale permission, and token misuse examples

Repository layout

agentic-identity-graph/
  src/agentic_identity_graph/
    api.py              FastAPI entry point
    graph_model.py      NetworkX identity graph
    authz.py            Runtime authorization engine
    schemas.py          Request and response models
  examples/
    allow_read.json
    allow_write.json
    deny_prompt_injection.json
    deny_missing_scope.json
    deny_cross_tenant.json
  tests/
    test_authz.py
  docs/
    threat-model.md
  requirements.txt

Quick start

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

uvicorn src.agentic_identity_graph.api:app --reload

Open:

http://127.0.0.1:8000/docs

Example authorization request

curl -X POST http://127.0.0.1:8000/authorize \
  -H "Content-Type: application/json" \
  -d @examples/allow_read.json

Example response:

{
  "decision": "allow",
  "reasons": [
    "User can invoke agent",
    "Agent is allowed to use requested tool",
    "Required connector scopes are present",
    "Tenant and data-space boundaries are valid",
    "No blocking runtime risk signals were found"
  ]
}

Sample scenarios

Scenario	Expected decision	Why
Read CRM account through approved agent	allow	User, agent, tool, connector, and scope relationships are valid
Write CRM account with crm.write	allow	Sensitive action allowed with required scope and justification
Prompt injection attempts to trigger write	deny	Runtime risk signal blocks sensitive tool execution
Missing delegated scope	deny	Connector requires a scope that is absent from token/session
Cross-tenant access	deny	Request org does not match user/agent/tool graph context

Run tests

pytest

Design notes

This project intentionally uses NetworkX instead of Neo4j to keep the demo simple and easy to run locally. The same model can be moved to Neo4j, Neptune, JanusGraph, or another graph database for larger deployments.

In a production system, the policy layer would likely integrate with OPA/Rego, Cedar, Zanzibar-style relationship-based access control, or a custom authorization service.

Resume positioning

You can describe this project as:

Built a graph-based authorization prototype for enterprise AI agents, modeling users, agents, tools, connectors, workloads, scopes, policies, and data boundaries to evaluate safe delegated access decisions at runtime.