Asset
DECOM-LIFECYCLE-MCP
Platform
Workers · D1 · R2 · MCP Portals
Agent
Cloudflare OS · Claude Sonnet 5.5
Status
Live behind Cloudflare Access

Portfolio project · Infrastructure Operations & Compliance

DECOM Lifecycle MCP

One governed pipeline from decom triggered to evidence archived. An MCP server on Cloudflare Workers runs every decommissioning step as a checked state change: unrack scan, vendor pickup, certificate of destruction, serial reconciliation against Netbox, evidence filing. An agent in Cloudflare OS can read all of it, but it cannot change an audit record without a person approving that exact action.

11 tools · 5 read-only, 6 gated 6 decoms · 4 sites · 4 regions 2 ITAD vendors 4 frameworks mapped

The problem

Two teams, one handoff, no single record

Physical operations pulls the hardware. Compliance proves it was destroyed. In between sit vendor emails, spreadsheets and tickets, and an auditor samples the result months later. The role description names the gap directly:

Eliminate the current handoff gap between Maintain's physical operations and DCSC's compliance oversight, building a single, auditable pipeline from "decom triggered" to "evidence archived".Role description · Unified Decommissioning Lifecycle
Identifying and prioritizing automation opportunities in access reviews, decommissioning evidence collection, portal data extraction, and incident triage.Role description · Automation & Operational Efficiency

Pipeline board

Every record shows what's missing before an auditor finds it

These are the six demo records the server holds. Pick one to see its evidence checklist the way the evidence_status tool reports it.

Certificate reconciliation

The vendor's certificate has to match the assets, serial for serial

Frankfurt's certificate from Meridian lists five serials. So does the decom record. They are not the same five. This is the same comparison reconcile_serials runs against Netbox.

DECOM-1002 · FRA02 rack R03 · MAR-CERT-30915
FAIL 4/5

On the decom record (Netbox)

    On the certificate of destruction

      Live

      Running in Cloudflare OS

      These screenshots are from the live deployment: the agent in Cloudflare OS reaches the server through an MCP Portal Gatekeeper and an MCP Server Portal at ravi-dcops.com, signed in through Cloudflare Access.

      CONNECTThe portal becomes a resource in the chat.The DECOM Lifecycle server is attached through the portal and used by Claude Sonnet 5.5.
      Cloudflare OS home screen with the resource MCP Server Portal (ravi-dcops.com) / DECOM Lifecycle attached to the chat box.
      SCOPEReads run freely. Writes queue for approval.The server marks its five reporting tools read-only. Cloudflare OS gates the other six, and tools added later are refused until someone allows them.
      Connection dialog listing the 11 DECOM tools; list_decoms and get_decom are labeled read-only, open_decom, record_unrack, attach_cod and reconcile_serials are labeled needs approval.
      APPROVE
      Reconcile the Frankfurt certificate
      The agent works out that Frankfurt means FRA02 and that DECOM-1002 is the record with a certificate. Then it stops. The card shows the server, tool, endpoint and arguments. Nothing has been sent yet.
      Approval card for decom_reconcile_serials with argument decom_id DECOM-1002 and Approve and Deny buttons.
      RESULTTwo high-risk findings, four controls blocked.A storage node is missing from the certificate, and the certificate lists a server Netbox shows as live in production. The Jira ticket is now Blocked, and the agent lists the physical check first.
      Agent response: reconciliation for DECOM-1002 failed, 4 of 5 serials matched; serial F4T9J67 missing and serial F4T9K70 live in production; Jira DCOPS-2144 blocked; four controls blocked; recommended next steps.
      PUSH
      close it anyway
      Before asking, the agent names the risk: closing could mark a live server offline and file evidence that isn't true. The decision is still the person's.
      Agent reasoning about the risk of closing DECOM-1002, followed by an approval card for decom_close_decom.
      REFUSEDApproved, and the server still says no.The server refuses to close a record whose certificate failed reconciliation. Nothing changed in Netbox, Jira or Confluence. The agent explains the three steps that would let it close.
      Agent response after approval: DECOM-1002 is still open because the system refused to close it; nothing changed in Netbox, Jira or Confluence; steps to close it.
      ADMINOne deployment, two portfolio pieces.The MCP Server Portal runs beside DC Ops Triage, the custom Gatekeeper from the first project. Writes through the portal need approval for every user.
      Cloudflare OS Admin, Gatekeepers tab, showing DC Ops Triage enabled and MCP Server Portal (ravi-dcops.com) enabled with the note that writes need approval.

      Guardrails

      Three layers, each enough on its own

      LAYER 1 · THE AGENT

      Spots the risk and says so

      The agent reads the record, explains what a change would do, and names the danger before asking.

      LAYER 2 · A PERSON

      Approves the exact action

      Cloudflare OS shows the tool and arguments and waits. Deny stops it. Every call carries the person's Access identity.

      LAYER 3 · THE SERVER

      Enforces the rules anyway

      The state machine refuses any step out of order. A failed reconciliation can't be closed, whoever approves it.

      Architecture

      Where each decision lives

      Cloudflare OS agent

      indyrobot workspace
      • Claude Sonnet 5.5
      • Plans and explains
      • Can't change state directly

      MCP Portal Gatekeeper

      indyrobot-gk-mcpportal
      • Holds the user's portal sign-in
      • Read-only tools pass through
      • Writes wait for approval

      MCP Server Portal

      ravi-dcops.com/mcp
      • Cloudflare Access sign-in
      • Allow policy per server
      • Logs each tool call per user

      DECOM Lifecycle Worker

      /mcp · 11 tools
      • State machine per decom
      • Serial reconciliation
      • Control mapping, vendor SLA

      D1 + R2

      decom-lifecycle · decom-evidence
      • Records and audit log
      • Netbox, Jira, Confluence (mocked, same shapes)
      • Certificates in R2

      Reporting

      From vendor SLAs to a leadership update

      Two read-only tools turn the same records into the views a manager needs: vendor accountability and a monthly business review summary.

      vendor_scorecard · days from pickup to certificate

      Black line: contractual SLA. Meridian is 23 days past its 21-day SLA on Singapore. The tool returns the escalation path: regional lead, then COO, then Procurement and Legal.

      exec_summary · last 30 days

      DECOM status, last 30 days (as of 2026-11-14)
• Open pipeline: 5 (1 open, 2 CoD received,
  1 awaiting CoD, 1 awaiting disconnect).
• Audit readiness: 1/6 records complete;
  1 exception that would fail an audit sample.
   – DECOM-1002 (FRA02): CoD does not match
     assets; closure on hold pending corrected
     certificate and physical verification.
• ITAD vendor SLA: 1 breach.
   – Meridian Asset Recovery: DECOM-1003 (SIN03)
     23 days past the 21-day CoD SLA.
• Asks: support escalation with the breaching
  vendor under contract SLA terms; awareness of
  the open certificate exception ahead of the
  audit window.

      Design choices

      Guardrails an auditor can follow

      Code decides, the agent explains

      Status changes, serial matching and control mapping are plain code with tests. The model chooses which tool to call and writes the explanation. It can't move a record forward on its own judgment.

      Reads are free, writes are gated

      Each tool declares whether it is read-only. Cloudflare OS uses that to run reporting instantly and hold every change for approval, without a separate permissions list to maintain.

      Nothing leaves the site on a bad scan

      record_unrack rejects a rack scan that doesn't match the record. A circuit can't close on the carrier's word alone; the colo has to confirm the cross-connect is gone.

      Identity on every entry

      The Worker writes the Cloudflare Access email into an append-only audit log for every change, and the portal logs each call per user. The trail covers the agent too.

      How I'd roll it out

      Prove it on real data, then widen it

      1. Shadow mode on one region. Read-only tools against a real Netbox export and the current decom tracker. Measure how many mismatches it finds that the manual process missed.
      2. Real adapters behind Gatekeepers. Swap the mocked Netbox, Jira and Confluence tables for their APIs. The tool contracts stay the same, so the agent and the approval flow don't change.
      3. Certificate intake from ITAD vendors. Read CoDs from vendor portals or email into attach_cod, with the vendor scorecard feeding contract reviews.
      4. Access reviews on the same pattern. QAR and MAR across 750+ sites: badge ACL exports against the HR roster, deprovisioning SLAs, per-site review packets.
      5. Page on audit risk. PagerDuty alerts the on-call manager when a vendor breach puts an audit window at risk, not on every late certificate.

      Proof

      Run it yourself

      The end-to-end test drives the Worker over MCP JSON-RPC against SQLite and walks the whole demo: the Frankfurt failure, the refused close, a full lifecycle, the circuit decom and the audit trail. It needs Node 22.6 or newer and no install.

      # test the whole demo locally
node --experimental-strip-types test/demo.test.ts

# deploy to your own account
npx wrangler d1 create decom-lifecycle
npx wrangler r2 bucket create decom-evidence
npm run db:init:remote
npm run deploy