I built an AI agent runtime security platform solo — now selling it for $9,999

September 7, 2026

Hey IH,

After several months of solo building, I'm selling Custodyn — a runtime security and trust infrastructure platform for AI agents.

What it does:
AI agents autonomously execute code, send emails, make payments with no oversight. Custodyn sits inside agent code via SDK — blocks risky actions, routes medium-risk to human approval queue, logs everything in a tamper-evident audit trail.

Three ways to integrate:

SDK — pip install or npm install, one line of code
Reverse proxy gateway — zero code changes, route traffic through Custodyn
Sentinel CLI — system-wide monitoring (in development)

What's included:

Live platform at custodyn.app
Python + JS SDKs on PyPI and npm (MIT licensed)
LangChain, LangGraph, CrewAI, AutoGen, MCP, Claude Code, OpenAI Agents SDK integrations
Human approval queues, policy engine, multi-tenant dashboard
Role-based access control — Owner, Admin, Operator, Viewer roles
Multi-tenant architecture — serves multiple organizations from one platform
Full security pentest done
Open-core model ($49–$2000/mo tiers)
60 day handover support

Pre-revenue. Full acquisition.

Listed on IndieMaker:
👉 indiemaker.com/listings/custodyn-ai-agent-security-platform

DM me or email founder@custodyn.app

Atul

custodyn

posted to

Custodyn

Say something nice to custodyn…

Post Comment

1

The runtime authorization layer makes sense to me. The part I’d pressure-test is what the audit trail is allowed to claim after the decision. If Custodyn returns BLOCK before anything crosses the enforcement boundary, that can be strong evidence of prevention. But if an action has already been dispatched — or execution crosses into a provider you no longer control — an internal BLOCK record doesn’t necessarily establish that the downstream consequence was prevented. I’ve ended up separating this into Authorization → Dispatch → Execution → Downstream Confirmation for that reason. Have you tested the ambiguous case yet: authority changes or a block occurs after dispatch, and the external system gives you insufficient evidence to establish whether the consequential action completed? That’s the case where I’ve found a binary allow/block result starts needing a third state: unresolved.

SuperMcG

·
3 days ago
·
Reply
1. 1
  
  That’s a very good distinction, and I agree that the audit trail shouldn’t claim prevention beyond what the enforcement boundary can actually establish. The strongest case for Custodyn is a BLOCK before dispatch: the authorization decision happened before the consequential action crossed the enforcement boundary, so the audit record can establish that Custodyn prevented that dispatch. The ambiguous case you described is different. Once an action has been dispatched and control moves to an external provider, a later BLOCK or timeout doesn't necessarily establish what happened downstream. I hadn't framed the lifecycle explicitly as Authorization → Dispatch → Execution → Downstream Confirmation, but I think that's a useful model. An UNRESOLVED state would make sense for cases where execution status can't be established rather than forcing the system into an inaccurate allow/block interpretation. Appreciate you raising this — this is exactly the kind of edge case that matters if runtime authorization is going to be treated as an infrastructure/security boundary rather than just another policy layer.
  
  custodyn
  
  ·
  3 days ago
  ·
  Reply
  1. 1
    
    Exactly. I think the interesting part is that these models may actually be complementary rather than competing.
    If Custodyn blocks before dispatch at an enforcement boundary it controls, then “prevented dispatch” is a strong, defensible claim. There’s no reason to weaken that to UNRESOLVED.
    The uncertainty only begins once the action crosses a boundary where the enforcing system can no longer establish consequence truth.
    That’s why I’ve found it useful to keep two questions separate:
    What did the control provably enforce?
    and
    What consequence can the available evidence provably establish?
    Sometimes those line up perfectly. Sometimes they don’t.
    A runtime authorization layer that can strongly prove the first, combined with an evidence model that refuses to overclaim the second, feels like a much stronger security story than asking either layer to prove something outside its observation boundary.
    Really interesting architecture. I’d be interested to see how Custodyn handles that boundary as you develop it.
    
    SuperMcG
    
    ·
    3 days ago
    ·
    Reply
    1. 1
      
      Exactly. I think that distinction makes the boundary much clearer. Custodyn’s strongest guarantee should be what it can provably enforce before dispatch, while the evidence layer should be explicit about what can and cannot be established downstream. Really appreciate the perspective. Have you dealt with this boundary in a production system? The way you describe it sounds like it comes from practical experience.
      
      custodyn
      
      ·
      2 days ago
      ·
      Reply
      1. 1
        
        That’s a fair question. Not from operating Custodyn’s exact pattern in production, so I don’t want to imply that. The boundary came out of the assurance work I’ve been doing around consequential agent actions, particularly by stress-testing cases where authorization, dispatch and downstream consequence stop lining up cleanly. The recurring failure case was surprisingly simple: a system could prove its own control decision, but then make a stronger claim about the downstream outcome than its evidence actually supported. We’ve since tested that distinction through several bounded, independently frozen scenarios with other builders and assurance models. The useful result hasn’t been that everyone implements the same architecture — they don’t — but that the same evidence boundary keeps appearing. That’s why your Custodyn example caught my attention. A BLOCK before dispatch looks like a genuinely strong enforcement claim. After dispatch, I’d want a different evidence source before making a claim about consequence. I’m curious whether you’ve encountered that second case in Custodyn yet — an action legitimately ALLOWed through the gateway, but where the downstream result later became ambiguous?
        
        SuperMcG
        
        ·
        2 days ago
        ·
        Reply
        
        1
        
        Not in the sense you're describing. In the current Custodyn SDK, we treat ALLOW as the authorization decision at the outgoing enforcement boundary. Once ALLOW is returned, the guarded action proceeds normally and any response from the external system goes back to the application. Custodyn isn't currently acting as a proxy for that inbound response or independently determining whether the downstream consequence ultimately occurred. So I think your distinction is useful: Custodyn can strongly establish what it authorized or blocked at its enforcement boundary, but we shouldn't make a separate claim about downstream consequence that Custodyn doesn't actually observe. That boundary is something I'm going to look at more closely.
        
        custodyn
        
        ·
        2 days ago
        ·
        Reply
        
        1
        
        That makes sense, and I think ALLOW is actually where the distinction gets most interesting. If Custodyn can prove that a specific action was authorised at the outgoing enforcement boundary, that is already a strong and useful claim. The question after that is simply a different one: what evidence, if any, can bind that authorised attempt to the downstream consequence? The awkward case is when ALLOW is followed by a timeout or ambiguous provider response. The authorization decision is still known, but the consequence may not be. Treating those as separate evidence states avoids accidentally turning “we authorised the attempt” into either “it executed” or “it didn’t execute.” That separation becomes especially important if the application is deciding whether it is safe to retry. Really interesting boundary to explore.
        
        SuperMcG
        
        ·
        2 days ago
        ·
        Reply
        
        1
        
        Yes, that makes sense. I agree that the retry question is where the distinction becomes particularly important. Custodyn's responsibility is the authorization boundary — whether the agent is permitted to initiate the action. Once the action is dispatched, determining whether a retry is safe can depend on the downstream provider's response, idempotency guarantees, request IDs, or another confirmation mechanism. So I agree that an ALLOW shouldn't itself be interpreted as either “the consequence definitely happened” or “the consequence definitely didn't happen.” It establishes that the action was authorized to proceed. The retry/idempotency angle is a useful edge case to think about as we evolve the audit model.
        
        custodyn
        
        ·
        2 days ago
        ·
        Reply
        
        1
        
        Agreed. I think that gives us a pretty clean separation of responsibilities. Custodyn can answer: “Was this attempt authorised to leave the agent boundary?” Then, where the workflow warrants it, a separate evidence mechanism can answer: “What can we actually establish about what happened after it left?” The interesting part is that the second mechanism doesn't necessarily need to control execution. It needs to bind the authorised attempt to whatever authoritative downstream evidence is available — provider event, transaction ID, idempotency record, webhook, resource state, etc. — and preserve uncertainty when that binding can't be established. That way neither layer has to claim more than it can actually prove. I suspect there may be a useful architectural seam between those two responsibilities.
        
        SuperMcG
        
        ·
        2 days ago
        ·
        Reply