Intent‑Based Access Control: A Technical Primer

Intent‑Based Access Control (IBAC) is not just “ABAC with a buzzword.” It’s a shift from “who can do what” to “for what purpose, under what conditions, and across which resources.” In an agentic‑AI and Zero‑Trust world, IBAC is becoming the semantic backbone of least‑privilege authorization. In this post, you’ll get a concrete technical model, a minimal ontology, code‑level patterns, and two fully fleshed‑out examples: a coding‑assistant agent and a healthcare‑agent workflow.

1. Core idea: from actions to intents

Traditional IAM answers:

• “Can this role read this table?”

• “Can this user invoke that API?”

IBAC instead asks:

• “For the current task and context, is this specific action over these resources allowed?”

Roughly, IBAC turns:

• subject:role → subject:task → action:resource#constraints

In practice, this means:

1. The user or system declares an intent (natural language or structured JSON).

2. The system parses that intent into a fine‑grained authorization tuple (e.g., tool:read#db:patients[pii=true]).

3. An authorization engine (e.g., Cedar, OPA, OpenFGA) evaluates that tuple against policy before every tool call.

If the later LLM logic is hijacked or mis‑guided, it doesn’t matter: the engine still enforces exactly what was permitted by the original intent.

---

2. Technical architecture of IBAC

A minimal IBAC stack looks like(See also Figure 1):

1. Intent parser (LLM or small classifier)

   • Maps user request into a structured Intent object.

2. Policy generator / mapper

   • Translates Intent into one or more FGA‑style tuples: principal:action#resource.

3. Authorization engine (e.g., Cedar, OPA, OpenFGA)

   • Evaluates each tuple at runtime.

4. Tool gateway / MCP router

   • Blocks any tool call whose tuple isn’t approved.

At runtime, the flow is:

• User → Intent parser → Intent(task=“xxx”, scope=[…], constraints={…})

• Policy mapper → [“tool:query_db#table:patients”, “tool:send_email#channel:internal”]

• Agent → Tool calls → Gateway → Authorization engine → DENY / ALLOW for each tuple.

Figure 1: Technical architecture of IBAC

3. A minimal IBAC ontology

You don’t need a “unified global ontology of intent” to ship useful IBAC. Instead, design a lightweight, domain‑specific ontology with a small vocabulary of entities and relations. For AI agents and healthcare, consider:

Core concepts

• User / Agent

• Task (e.g., “incident_report”, “clinical_note_review”, “finance_audit”)

• Action (e.g., read, write, query, send, update, delete)

• Resource (e.g., table:patients, table:claims, channel:slack, file:incident.log)

• Constraint (e.g., max_rows=100, sensitivity=“phi”, time_bound=15m)

Core relations

• User intends(Task)

• Task requires(Action on Resource)

• Action is_constrained_by(Constraint)

• Policy governs(Task, Scope)

With this schema, you can express:

• “For task incident_report, agent can read table:logs and table:events, but only up to 1000 rows.”

• “For task clinical_note_review, user can read table:patients where sensitivity=phi, but cannot export or delete.”