Threat-modeling AI systems

Everything else on this site is a system being threat-modeled by people, with AI tools helping write the models. This page is about the harder recursive case: threat-modeling the AI systems themselves — agents with file access, tool calls, and permissions that don't map cleanly onto the human-operator assumptions most threat-modeling methodology was written for.

The evidence already on this site

The clearest instance is in the agentic-workflow threat model covered on /practice/two-modes/: among its eight scored threats is prompt injection via file content, rated Medium likelihood / High impact. That a file — not a chat message, not a direct instruction — is the injection vector is the detail that matters: an agent that reads untrusted content as part of its normal job has an attack surface a purely conversational model does not.

Agent permissions as a threat-model object

An agent's permission set is not the same object as a human user's role. A role is usually static and reviewed rarely; an agent's effective permissions are the union of what its harness grants, what its tools can reach, and what the content it processes can persuade it to do — which is exactly why prompt injection via file content scores as a distinct threat rather than a variant of an existing one. The network carries dedicated work on this precise boundary — permission games and browser isolation for agents are active subjects elsewhere on sgit.ai; this site's own part is narrower: what a threat model of an agentic workflow needs to say about permissions, not the permissions substrate itself.

What is measured here versus asserted elsewhere

Where this stops and a sibling starts

Non-human identity and agent-permission mechanics as a subject in their own right belongs to the parent network rather than this site — see /network/ for the deconfliction table. This page's job is narrower and stays that way: what a threat model needs to say when the system under review is itself an AI agent.