Least-Privilege Access Review Workbench: Remove Risky Access

Trace every hidden access path, remove unnecessary grants, and preserve the one dependency production still needs.

Comment

Inspiration

Offboarding reviews look simple until access is inherited through nested groups, project roles, personal tokens, and shared operational dependencies. The hardest part is not listing permissions; it is showing why each permission exists, predicting what would break, and keeping confirmation in a visible browser safety boundary. We built the Least-Privilege Access Review Workbench to demonstrate how WebMCP can make that reasoning structured and visible without turning an AI agent into an invisible administrator.

What it does

The demo opens on one urgent synthetic case: Alex Morgan's contract ended Friday, but production deploy and customer-data export access remain. An agent can use nine top-level imperative WebMCP tools to resolve Alex's identity, compute effective access, trace four distinct paths, flag risks, and simulate a least-privilege change.

The first simulation intentionally finds a breakage: an on-call Incident Relay depends on a rollback grant tied to Alex. The plan is revised to remove exactly five unnecessary grants while reassigning one rollback dependency to a service identity. The agent can preview and stage that plan, but no WebMCP tool revokes or confirms it. A visible normal page control commits only the mocked in-memory review, after which a read-only receipt becomes available. Ordinary browser actuation may still reach that control, subject to Codex/browser safety confirmation.

The centerpiece is a live SVG graph with red risk paths, amber staged removals, and a green preserved dependency, plus before/after exposure, path explanations, an activity timeline, and WebMCP status. A clearly labeled step-through rehearsal drives the same domain service when native WebMCP is unavailable and holds every intermediate state until the next click.

How we built it

The Least-Privilege Access Review Workbench is a static Vite + React + TypeScript application with plain CSS and no backend, secrets, or external APIs. A deterministic domain service models 50 users, 10 groups, 3 applications, four effective paths, six sensitive grants, simulation, staging, confirmation, and receipt state.

WebMCP tools are registered imperatively from the top-level page. The integration prefers document.modelContext, falls back to navigator.modelContext for older Chrome previews, awaits every registerTool call inside try/catch, and uses an AbortController for registration cleanup. Tool callbacks follow the current execute(input, { signal }) shape, validate inputs in code, and return only after visible state has synchronized. Accurate read-only and untrusted-content annotations describe each contract.

Vitest covers cycle-safe nested groups, exact scenario counts, cancellation, registration cleanup, validation, and the rule that no durable mocked mutation occurs before visible confirmation. Tests also verify atomic tool registration, stale-plan rejection, and consistent post-confirmation ownership. Vercel and Netlify configs provide top-level static hosting, a tools=(self) permissions policy, origin isolation, and no iframe path.

Challenges, learnings, and what is next

The central challenge was designing a useful agent workflow around a strict safety boundary. “Stage” has to be stateful enough to make the plan reviewable, while remaining clearly different from “apply.” Sharing one domain service between WebMCP, the UI, and rehearsal avoided hidden agent-only behavior and made the safety claim testable.

We also learned that effective access is a graph problem, not a flat-role problem. Cycle-safe traversal and path-level explanations matter as much as the final count. Compatibility required targeting today's real surface: top-level imperative tools, asynchronous registration, current execution cancellation, and no dependency on declarative or iframe discovery in OpenAI Site Tools.

Next, the same interaction model could be connected to read-only exports from real identity systems and to an existing, separately authorized change-management flow. That would require production authentication, policy evaluation, audit storage, tenant isolation, and security review. This prototype does not claim to prevent breaches, certify compliance, or replace authoritative access owners; it demonstrates a transparent least-privilege review pattern.

How we used AI

The application exposes structured WebMCP operations to an external AI agent. The agent can sequence identity lookup, path tracing, risk analysis, simulation, revision, and staging while the same evidence appears in the UI. The application itself contains no embedded model API, and the synthetic access calculations are deterministic rather than model-generated. The recorded demo is documented as using OpenAI Codex Site Tools; no additional native client testing is claimed.

How we used Codex

OpenAI Codex was the external agent for the recorded WebMCP workflow, as documented in the repository's demo materials and native-validation history. During submission preparation, Codex inspected the source and assets, ran the 30 automated tests and TypeScript checks, checked the public app/repository/video endpoints, and organized the draft into the event's required fields. The repository also credits the WebMCP Agent Skill from the Web AI Agent Skills collection. No more specific code-generation history or use of additional AI tools is claimed without supporting evidence.

Testing instructions

No login or credentials are required. Open the live URL as a top-level page in a WebMCP-capable browser. Confirm nine tools are available, then ask the agent to review Alex Morgan's remaining production and export access, simulate removing it, preserve the on-call dependency, and stage the revised plan without confirming it. The unsafe simulation should report one rollback dependency breakage. The revised plan should propose five removals and one reassignment. A receipt must not exist before the visible confirmation control is activated. After the reviewer confirms the mocked plan, the receipt and current access view should show zero sensitive grants for Alex and one rollback grant owned by svc-oncall-relay.

Reload or use Reset case to start again. The labeled rehearsal is a UI fallback, not evidence of native WebMCP discovery or agent tool execution.

Known limitations

Synthetic single-case data, in-memory state that resets on reload, illustrative exposure scores, and no production IAM enforcement, authentication, or compliance guarantee. Browser support may vary. The live deployment uses GitHub Pages; the Vercel/Netlify custom-header configurations are alternatives, not claims about headers actually emitted by GitHub Pages.

Built With

Share this project:

Updates

Submission history