Prune

WebMCP powered access-lineage infrastructure for SaaS. Trace and contain every credential created by a compromised session while preserving trusted access.

Comment

Inspiration

Revoking a suspicious login does not necessarily secure an account.

An attacker who obtains one browser session can create independent ways back in: API keys, connected-application grants, access tokens and secondary sessions.

Traditional security pages display these resources as separate lists, leaving the account owner to determine how they are related.

A user may revoke the suspicious session, watch it disappear and reasonably believe recovery is complete while an API key created by that session continues working.

Prune was inspired by a different mental model: Git-style lineage for account access.

Instead of showing only which credentials exist, Prune records where each credential came from. When one login becomes untrusted, the owner and their personal browser agent can investigate and contain everything created from that login without destroying unrelated trusted access.

## What Prune does

Prune is embedded access-lineage and account-takeover containment infrastructure for SaaS applications.

Every access-producing action records:

  • The organization and account
  • The user and actor session
  • The parent credential
  • The newly created credential
  • The credential type
  • The creation time
  • Redacted request metadata

This produces a persistent directed graph:

  Unfamiliar Windows session
  ├── Quarterly billing export API key
  ├── Unfamiliar Data Sync application
  │   └── Child access token
  └── Secondary access

  When the owner identifies an unfamiliar login, Prune opens a recovery incident around that branch.

  The owner and their personal agent can then:

  1. Trace every descendant credential.
  2. Inspect usage and security evidence.
  3. Classify recognized and unrecognized activity.
  4. Preserve trusted devices and operational automation.
  5. Compare counterfactual containment strategies.
  6. Check lockout and operational risk.
  7. Build an immutable recovery plan.
  8. Complete independent step-up verification.
  9. Approve the exact credential set.
  10. Execute one short-lived containment capability.
  11. Verify every revoked and preserved resource.
  12. Generate a permanent recovery receipt.

  ## Why WebMCP is essential

  This workflow crosses sessions, API keys, connected applications, tokens, usage evidence, recovery policy and approval state.

  Visual browser automation would require an agent to interpret several dangerous settings pages and guess which controls correspond to which credentials. That is too ambiguous for account recovery.

  A single secure_account tool would also be unsafe because it would hide the investigation and human decisions behind one opaque action.

  Prune instead exposes 28 granular WebMCP tools covering:

  - Incident investigation
  - Session and credential inspection
  - Descendant tracing
  - Human classification
  - Preservation constraints
  - Counterfactual simulation
  - Lockout and operational-impact checks
  - Immutable plan creation
  - Step-up verification status
  - Exact-plan approval
  - One-time containment
  - Independent outcome verification
  - Recovery-receipt generation

  Tool availability changes with the incident’s server-controlled phase.

  Investigation tools are available first. Planning tools appear only after sufficient evidence has been classified. execute_approved_containment appears only after independent step-up verification and exact human approval. It disappears after its one allowed execution.

  Retaining an old browser tool reference provides no authority because every request is authenticated, tenant-scoped, schema-validated and checked against current server policy again.

  ## Human, agent and website collaboration

  Each participant contributes information the others do not possess.

  The website knows:

  - Which credentials exist
  - Which session created each credential
  - Their parent-child relationships
  - Their current status and usage
  - Which actions policy permits

  The personal agent can:

  - Investigate structured evidence
  - Trace the complete credential branch
  - Identify unresolved decisions
  - Ask focused questions
  - Compare containment alternatives
  - Explain consequences
  - Verify the final result

  The human knows:

  - Which devices belong to them
  - Which applications they intentionally connected
  - Which automation must remain operational
  - Which activity they recognize
  - Whether the exact recovery plan should be approved

  The agent never determines authorization. It never receives passwords, raw API keys, access tokens, verification codes or execution cookies.

  ## What we built

  Prune includes:

  - Independent server-side browser sessions
  - Secure HTTP-only session cookies
  - One-time API-key and application-token issuance
  - Digest-only secret persistence
  - Connected-application grants and usable child tokens
  - A normalized PostgreSQL credential graph
  - Parent-child validation and cycle rejection
  - Ancestor and descendant traversal
  - Usage and security-event recording
  - Manual session-only revocation
  - Recursive branch containment
  - Incident creation and evidence collection
  - Human classifications
  - Preservation constraints
  - Three counterfactual containment strategies
  - Lockout and operational-impact analysis
  - Canonical immutable plan hashes
  - Short-lived step-up verification
  - Exact human approval
  - One-time execution authority
  - Idempotent revocation
  - Post-execution verification
  - Permanent recovery receipts
  - Server-sent real-time incident updates
  - 28 dynamically exposed WebMCP tools
  - Secret-redacted WebMCP results and audit trails
  - A complete manual fallback when WebMCP is unavailable
  - A SaaS integration control plane
  - Signed event ingestion and replay protection
  - Instrumentation coverage checks
  - Confirmed revocation webhooks
  - A reference TypeScript integration SDK
  - Automated unit, integration, multi-browser and accessibility tests

  ## What is real in the demonstration

  Northstar is a working reference SaaS application protected by Prune.

  The demonstration creates two genuine independent browser sessions. The unfamiliar browser issues a real API key and connects an application that receives a real child token. These credentials authenticate against protected endpoints.

  The owner then revokes only the visible suspicious session.

  The unfamiliar browser is signed out, but the independently issued API key still returns HTTP 200. This proves why ordinary session revocation is incomplete.

  A fresh recovery scenario is then processed through Prune’s WebMCP contract. The incident is investigated, the four-credential branch is classified, preservation constraints are recorded and an immutable plan is built.

  The owner performs step-up verification and approves the exact plan. Prune exposes one short-lived execution capability and recursively revokes the approved branch.

  After containment:

  - The attacker API key returns HTTP 401.
  - The connected application token returns HTTP 401.
  - The unfamiliar session remains signed out.
  - The owner remains authenticated.
  - The trusted phone remains active.
  - Deployment automation remains active.
  - Execution authority is consumed.
  - A permanent recovery receipt records the outcome.

  No incident, credential relationship, status code, plan, approval, revocation result or receipt shown in the operational interface is hard-coded.

  Native tool discovery was verified in ChatGPT’s in-app browser. The recorded recovery sequence uses a deterministic browser-agent evaluation against the same registered WebMCP contract, live deployment, authenticated routes, application services and production database.

  ## How WebMCP was implemented

  The authenticated incident page feature-detects:

  document.modelContext.registerTool(...)

  Prune registers only the tool contracts permitted for the incident’s current phase. Registrations are owned by an AbortController, allowing obsolete capabilities to be removed immediately when state changes.

  Every tool calls:

  /api/incidents/:incidentId/webmcp/:tool

  The server then:

  1. Authenticates the browser session.
  2. Scopes organization, account and incident ownership.
  3. Validates the tool-specific input with Zod.
  4. Rechecks the current incident phase.
  5. Calls the shared application service.
  6. Applies security policy.
  7. Redacts sensitive results.
  8. Records a structured audit event.

  The human interface, HTTP routes and WebMCP tools therefore use the same authorization, lineage and recovery services.

  ## Challenges

  The hardest challenge was preserving a useful agent experience without transferring security authority to the agent.

  Recovery required several distinct boundaries:

  - Classification must come from an explicit human statement.
  - Step-up credentials must go directly to Prune.
  - Plan approval must remain a human website action.
  - Execution must match an immutable plan hash.
  - Authority must expire and work only once.
  - Suspicious sessions must not approve their own containment.
  - Verification must independently inspect the final state.

  Another challenge was representing one recovery simulation consistently across the manual interface and WebMCP. We found and corrected a mismatch through a real browser-agent run, then added a regression test covering the complete persisted simulation and live-refresh path.

  ## What we learned

  WebMCP is most valuable where a website possesses authoritative structured state, an agent can investigate complexity and a human must retain consequential judgment.

  The strongest design was not to give the agent more authority. It was to give the agent better evidence and narrower, phase-bound capabilities.

  We also learned that agent-native interfaces need explicit capability lifecycles. A tool that was safe during investigation may be inappropriate during execution. Server-enforced dynamic availability makes the agent experience clearer and safer.

  ## Potential impact

  Prune is designed for small and mid-sized SaaS platforms with valuable customer accounts but limited internal recovery infrastructure.

  Potential adopters include:

  - Developer platforms
  - API companies
  - Cloud-management products
  - Automation services
  - Financial SaaS applications
  - Infrastructure dashboards

  A SaaS company can adopt Prune gradually: connect one credential surface, ingest signed lifecycle events, observe instrumentation gaps, add provider-specific adapters and enable containment only after coverage becomes trustworthy.

  ## What makes Prune different

  Other security products show which access exists.

  Prune shows where access came from.

  That lineage enables a new recovery primitive: remove everything created by one compromised access path while preserving the rest of the account.

  Prune is not a chatbot wrapper, a generic security dashboard or a scripted revoke demonstration. It is a working credential-lineage and human-gated containment system designed for the agent-native web.

Built With

Share this project:

Updates

Submission history