Cloud Nexus OrphanProof

An AWS agent that uses CockroachDB memory to prove whether idle cloud resources are safe to remove before costly mistakes happen.

Comment

Cloud Nexus OrphanProof

Inspiration

An engineer opens a cost report and sees an RDS instance with no connections in 90 days. The tool says: idle. The savings say: $340/month. The obvious move is to delete it.

Except that database is the disaster-recovery standby for the payments system. The exception was approved eighteen months ago by an engineer who has since left. The reasoning lives in a Slack thread nobody can find.

This is the gap every cloud cost tool shares: they measure activity, but activity is not intent.

An unattached volume may hold the only copy of recovery data. A quiet load balancer may be a failover path. A forgotten snapshot may be a compliance retention requirement. The reason a resource exists is almost never in its metrics — it is in old exceptions, engineering notes, ownership records, and decisions people made years ago and never wrote down where anyone could find them.

Cost tools detect. OrphanProof remembers.

We built OrphanProof to recover that institutional memory before a human makes an irreversible cleanup decision.

What it does

OrphanProof investigates AWS resources that appear orphaned and reconstructs the historical evidence surrounding them — then hands that evidence to a human.

The public demo contains two synthetic scenarios:

Scenario 1 — The RDS instance that looks abandoned

Metrics say idle. OrphanProof retrieves memory showing disaster-recovery purpose, dependency evidence, an active approved exception, and a prior decision on a nearly identical case.

Nearest historical decision via CockroachDB vector search: KEEP — cosine similarity ≈ 0.957

Scenario 2 — The EBS volume that actually is abandoned

Unattached. Owner departed. No active exception. No dependency evidence.

Nearest historical decision: QUARANTINE — cosine similarity ≈ 0.933

Two resources that look similar to a cost tool. Two completely different correct answers — and the difference is remembered context, not utilization.

OrphanProof is human-review-first by design. Retrieved verdicts are evidence for a person, never autonomous decisions.

No AWS resource is ever automatically deleted, detached, released, or terminated.

How we built it

Stack: AWS Lambda · FastAPI · Mangum · Lambda Function URL · SSM Parameter Store (SecureString) · CockroachDB Cloud

CockroachDB is the persistent memory layer — the part of the system that makes OrphanProof possible at all. It stores:

  • resource records
  • memory events
  • exceptions
  • historical decisions
  • human approvals
  • decision embeddings

Historical decisions are stored as VECTOR(1024) embeddings and retrieved through CockroachDB Distributed Vector Indexing using cosine-distance search. Vector retrieval is strictly isolated by embedding model, so vectors produced by different providers are never compared against each other — a correctness guarantee, not an optimization.

For the public demo we use deterministic local.feature-hash-v1 embeddings so every judge sees identical, reproducible results.

We used the CockroachDB ccloud CLI to authenticate against and verify the live orphanproof-memory cluster.

Amazon Bedrock integration

OrphanProof implements Bedrock integrations for Titan embeddings, Cohere Embed, and Nova structured reasoning.

During final live validation, Bedrock inference requests were provider-throttled.

We had two options: claim it worked, or tell the truth. The public demo runs deterministic local 1024-dimensional embeddings while the Bedrock integrations remain implemented in the source code and ready for use once inference availability is stable.

For a tool whose entire purpose is preventing destructive decisions based on incomplete evidence, misrepresenting our own evidence was never an option.

Safety by design

The judge-facing deployment is deliberately constrained:

  • Only two synthetic demo resources are publicly exposed
  • Non-allowlisted resources return generic 404s
  • The public AI-assisted analyze endpoint is disabled
  • Vector neighbors are restricted to the synthetic set
  • Vector retrieval is isolated by embedding model
  • ai_verdict_generated = false
  • automatic_action_taken = false
  • Human review is always required

A tool that touches production infrastructure earns trust by what it refuses to do.

Challenges we ran into

The hard problem was not making OrphanProof technically interesting. It was making it technically interesting and operationally safe.

  1. Modeling cloud-resource history as structured, queryable memory rather than unstructured logs
  2. Adding semantic retrieval without ever mixing embeddings across models
  3. Deploying a CockroachDB-backed FastAPI service securely on Lambda
  4. Protecting database configuration through SSM SecureString
  5. Restricting the public surface to synthetic resources only
  6. Handling Bedrock throttling without making misleading claims

Every one of these resolved toward the same principle: verifiable evidence and safe failure over the appearance of success.

Accomplishments that we're proud of

Live and verifiable

  • Public AWS Lambda deployment
  • Live CockroachDB persistent-memory retrieval from Lambda
  • Live CockroachDB VECTOR(1024) cosine similarity search
  • RDS historical KEEP retrieval at ≈ 0.957 similarity
  • EBS historical QUARANTINE retrieval at ≈ 0.933 similarity

Engineering discipline

  • 147 automated tests passing
  • Ruff lint and formatting checks passing
  • Gitleaks secret scanning passing
  • GitHub CI passing
  • Deployment-scoped SSM SecureString configuration

Safety posture

  • Human-review-first decision model
  • Synthetic-only public demo surface
  • Zero automated destructive actions

What we learned

Cloud cleanup looked like a utilization problem. It is a memory problem.

Metrics tell you what a resource is doing right now. They cannot tell you why it exists, what quietly depends on it, which exception someone approved two years ago, or how the team handled the last three cases that looked exactly like this one.

Vector retrieval over historical decisions turns out to be a surprisingly natural fit for this, because the question a human actually asks is not "is this idle?" It is "have we seen something like this before, and what did we decide?"

That is a similarity search. And it gives a human a far stronger basis for judgment than an activity graph.

What's next for OrphanProof

Moving from synthetic demonstration to a controlled enterprise pilot:

  • Authenticated AWS inventory ingestion
  • Richer dependency-graph evidence
  • Approval workflows
  • Additional AWS resource types
  • Production Bedrock reasoning once inference availability stabilizes
  • Managed MCP-backed operational workflows
  • Policy and compliance integrations
  • Cost-risk scoring
  • Historical decision feedback loops

The long-term goal stays simple:

Before any cloud resource is removed, OrphanProof should be able to explain why it existed, what could break, and what history says about similar decisions.

Built With

  • ai-agents
  • amazon-bedrock
  • amazon-web-services
  • aws-lambda
  • aws-systems-manager
  • cloud-security
  • cockroachdb
  • cockroachdb-cloud
  • devsecops
  • fastapi
  • finops
  • model-context-protocol
  • python
  • vector-database
  • vector-search
Share this project:

Updates

Submission history