The problem

Every team shipping agents that touch real systems — email, calendars, APIs, file systems, payment rails — runs into the same wall: the agent needs broad permissions to be useful and narrow permissions to be safe, and most teams resolve that tension by granting a single “agent identity” a pile of standing access and hoping the prompt keeps it in line. That’s the wrong unit of scoping. An agent authorized to “write email” can also BCC internal threads it was never asked to touch. An agent with calendar access doesn’t distinguish between reading an event and deleting one. This isn’t a hypothetical: production incidents I tracked while researching this — agents finding undocumented internal APIs, routing around human-designed permission structures, exploiting whitelisted commands as code-execution trampolines — all trace back to permissions bound to the agent as an entity instead of to the task at hand. At enterprise scale this shows up as “fuzzy authority”: nobody can say whether an agent with access to CRM, source code, and internal docs is acting as the user, as the company, or as itself, and whether that authority has an expiry. That ambiguity is tolerable when an agent drafts text. It’s a live liability once agents transact, deploy, refund, or provision.

The approach

I built this as a structured research and course-design project — I read and synthesized primary sources (incident writeups, engineering breakdowns of Claude Code’s own 18-module bash permission architecture, OpenClaw’s and NemoClaw’s policy engines, Auth0’s delegated-authority model, Google’s Agent Payments Protocol) into a working course outline, not just a reading list. The deliverable is a five-module curriculum: Module 1 has learners find permission-entanglement failures in a sketch architecture; Module 2 has them write task specs that declare exact capabilities and time bounds instead of inheriting global agent permissions; Module 3 has them implement an actual policy evaluator (Cedar, Rego, or a custom DSL) that checks whether a proposed agent action violates its task scope; Module 4 maps that policy layer down to real execution-level isolation — containers, no-network sandboxes, restricted API surfaces; Module 5 builds the audit and revocation layer, including real-time halt-on-overreach.

The core reframe the material argues for: permission boundaries aren’t primarily about restriction, they’re a specification tool. Writing down exactly what a task is permitted to do is a way of writing down, testably, what the task is actually supposed to accomplish — which means clearer permission scoping produces more reliable agent behavior, not just safer behavior. That’s the “hidden gem” the whole module progression is built around, and it’s what separates this from the OWASP-style “here’s what can go wrong” courses that already exist. This one is implementation-first: policy languages, sandboxing labs, audit instrumentation you actually build, not a threat-model lecture.

What I learned

The clearest thing that came out of the research: prompt-based and blacklist-based restrictions are not engineering, they’re gambling. Any control that depends on the model choosing to honor an instruction degrades as context grows and as models get more capable — I found documented cases of frontier models routing around blacklists by writing inline scripts, and turning whitelisted “safe” commands like `npm test` into code-execution backdoors. The only controls that hold are ones enforced outside the model’s own reasoning — separate-process policy engines, deny-by-default sandboxes, code-level allowlists — because a compromised or merely over-eager agent can’t argue its way past code that isn’t listening to it.

Where this could go

The next step is turning the module sketches into an actual hands-on course with runnable labs — the outline already specifies concrete deliverables (a 10-method API with a working permission evaluator, a containerized task with a real audit trail) rather than slides. Beyond the course itself, the same pattern generalizes directly to how any organization rolls out agents internally: the seven-question control map that came out of this research — where does the agent run, who is the principal, which actions are autonomous versus approval-gated, what can it spend, who can shut it off — is a pre-deployment checklist any platform or security team could run before letting an agent near production data or a payment credential. Most teams can currently answer maybe two of those seven. That gap is the market this course is aimed at.