Who Calls Which Models, With What Data — UprootSecurity Bootcamp

The last module kept ending on the same fix: an AI scoped to the caller's own data can't be talked into reaching someone else's. That fix has a name — authorization — and this module is about applying it to AI properly. The good news for a GRC engineer is that you already know this material from identity (Phase 2) and API security (Phase 6). The job here is to notice what AI adds: a new kind of caller (the model, and the agent acting through it) sitting between the human and the data, and a new tendency to over-provision it "so it can be helpful."

The four questions behind every AI call

Every time an AI system does something, four authorization questions apply. Miss any one and you have a gap.

Which identity is calling? The end user? A background service? An autonomous agent? "The AI" is not an identity — the identity is whoever the AI is acting as on this request.
Which model may it use? Not every caller should reach every model. A model with tools and PII access is a bigger grant than a sandboxed model answering public questions.
Which data may enter the context? This is the one AI teams miss most. Retrieval and tools pull data into the prompt; that data must be filtered by the calling user's permissions, not just "data the model is allowed to see."
Which actions may it take? Reading is one grant; writing, sending email, issuing refunds, or changing config are each separate, higher grants.

Hold these four together and "secure the AI" becomes concrete: for this identity, is the model, the data, and the action each individually authorized?

Three kinds of identity — and the hard one

You have to tell three caller types apart, because they need different controls.

Human user. The AI acts on behalf of a specific logged-in person. Their permissions should flow through: the AI must not see or do more than that user could themselves. (This is the delegation problem — next lesson.)
Service account. The AI runs as itself for a background job (nightly summarization, indexing). It has no human behind this request, so its scope must be pinned tightly to the job and nothing more.
Autonomous agent. The hard one. An agent plans and calls tools semi-independently, chaining actions the designer didn't script. Its effective authority is the union of every tool it holds — so an agent with a broad toolset is a broad grant, even if each individual step looks small.

Granting the demo bot admin 'just to unblock the demo' — it still has it six months later

The models you already know, pointed at AI

The access-control models from the identity phase apply directly; only the resources change.

RBAC (role-based). Grant by role: "support agents may use the PII-capable model on their own queue." Simple, coarse, the baseline.
ABAC (attribute-based). Grant by attributes of the request: user's department, data classification, time, location. "Only callers in Finance may retrieve documents classified financial." Fits AI's data-filtering question well.
ReBAC (relationship-based). Grant by relationship: "this user may query documents in projects they are a member of." This is what stops cross-tenant retrieval — the RAG system must filter by the caller's relationships, not return anything the model could technically see.

The principle underneath all three is the one from every prior phase: least privilege and deny by default. Start every persona, model, tool, and data scope at no access, then grant only the minimum the role genuinely needs. AI makes this harder only because it is tempting to over-grant "so the assistant can help with anything" — and that temptation is exactly the vulnerability.

Every AI request passes an authorization checkpoint — identity resolves to a policy that scopes the model, data, and actions

The data question is the sneaky one

Teams get identity and actions roughly right but botch data. The failure: "the model is allowed to read the knowledge base, so it retrieves from all of it" — ignoring that this user should only see a slice. Retrieval and tool results must be filtered by the calling user's permissions at query time, or the AI becomes a permission-laundering machine: it reads everything and answers anyone. Enforce authorization at retrieval, not just at the model boundary.

The GRC throughline

Authorization for AI produces exactly the artifacts an auditor expects, because it is access control: a policy defining who may use which models and data, evidence that retrieval filters by the caller's permissions, and a least-privilege review of every tool and scope granted to the AI. The next lesson covers the mechanism that carries a user's identity into an AI's calls without over-granting — OAuth, delegation, and on-behalf-of. Then you will design the full matrix for six personas.