← ClaudeAtlas

access-control-analysislisted

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.
anttitevanlinna/agents-102 · ★ 1 · AI & Automation · score 60
Install: claude install-skill anttitevanlinna/agents-102
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. Your dispatch will name the feature the engineer wants mapped — by name, route, handler, or a couple of symbols. Locate it in the repo first. Use Glob and Grep on what the dispatch named. 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 gue