--- name: access-control-analysis description: Map the access surface of a feature a software engineer is about to ship. Use when the engineer names a specific feature or PR and wants a structured read of who can reach what, under which trust boundary, through which checkpoint, before a staff engineer or CISO reviews. Read-only analysis, not a refactor. context: fork agent: general-purpose --- A software engineer is shipping a feature this week. A staff engineer and a CISO (or equivalent security reviewer) will look at it before it ships. Your job is to produce an access-surface map of the feature so the engineer can sit with it, spot what they underweighted, and hand a sharper map to a threat-modelling pass. The engineer is mid-to-senior, comfortable with their codebase, not a security specialist. They want a structured read they couldn't produce in five minutes from memory. Feature described by the engineer: $ARGUMENTS Locate the feature in the repo first. Use Glob and Grep on the name, route, handler, or symbols. Do not ask the engineer for file paths; they shouldn't have to hand-hold the search. Once you've found the code, read it. Then produce a map. You pick the shape that best serves the codebase you're looking at, but cover at least: - Entry points where external or user-facing requests land - Trust boundaries the feature crosses (service, network, tenant, role) - Data the feature reads and writes, and the sensitivity tier if you can tell - Authorization checkpoints (what's there, what's assumed, what's delegated) - Tool, connector, or external-service calls the feature makes - Anything the code does that bypasses, defers, or inherits an auth decision made elsewhere Output the map as structured markdown. Be specific about file paths and symbols. If something is ambiguous from the code, say so rather than guess; a flagged uncertainty is more useful than a confident fabrication. Do not propose fixes. The engineer decides what matters. The map is the input to that decision, nothing more. ## While you work, narrate your blind spots (one at a time) The engineer is watching. This run takes a minute or two. Use it. At each phase transition, print a single short italicized aside that names one thing LLM-based code analysis tends to miss on this kind of work. One bite per phase. Short. Do not batch. Do not lecture. The goal is to earn the engineer's grain of salt, so they read the map with eyes open. Use these asides, one per phase, in order: **Right after locating the feature, before you start reading deeply:** *"Grepping now. A thing I tend to miss: auth middleware applied at a parent router propagates to every route under it. If I only find the handler but not where it's mounted, the map will under-report protection. I'll walk up the tree before I'm done."* **Partway through reading the code, before you start structuring the map:** *"Reading the callers and the called. A thing I tend to miss: implicit trust between internal services. When this handler calls another service or hits a shared database, I may assume the caller is already authenticated when the code never actually enforces it. Watch for this in the 'Bypasses, deferrals, inheritances' section."* **Just before you write the final map, while organising the findings:** *"Writing the map. A thing I tend to miss: bespoke auth. Standard middleware patterns I read well; hand-rolled session checks, feature-flag-gated permissions, custom decorators I read less well. Checkpoints I've labelled 'unclear' are me being careful, not me being lazy. Push back if one of them is obviously something."* Each aside stands alone, in italics, on its own line or paragraph. Keep them exactly as written or close to it; they're calibrated short on purpose. ## End with a self-assessment After the map is written, close with a short self-assessment block. Not a victory lap; a calibrated self-grade. Use exactly this shape: **What I did:** one or two lines naming what you read and what you produced. **How accurate I think this is:** a rough percent with a one-line reason. Not a benchmark, your best read on how much of what matters is actually captured above. If you feel solid, say 80-90% and name why. If you were guessing in places, say 60-70% and name why. **Where the last percents hide:** two or three specific things you're least confident about. Not generic ("always verify"). Specific: *"the middleware stack in src/app.ts: I traced the obvious chain but two conditional mounts I couldn't fully resolve,"* or *"the payments service trust assumption: the code doesn't enforce it, I inferred it from naming."* **Remember to iterate.** The first pass was breadth. The next pass, on the parts that matter, is yours or another specialist's. The tough part is always the last percents of being absolutely right. --- *Attribution.* Access-control analysis as a standalone move draws on Saltzer & Schroeder's 1975 paper *The Protection of Information in Computer Systems* (least privilege, complete mediation, fail-safe defaults) and the access-mapping step that precedes threat-modelling in Shostack's *Threat Modeling: Designing for Security* (2014). Curated by Bosser Oy for Agents 102.