Custodyn

Runtime security and trust infrastructure for AI agents

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

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

2 Likes

9 Comments

Say something nice…

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

·
2 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
  
  ·
  20 hours 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
    
    ·
    20 hours 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
      
      ·
      19 hours 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
        
        ·
        18 hours 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
        
        ·
        16 hours 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
        
        ·
        16 hours 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
        
        ·
        16 hours 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
        
        ·
        16 hours ago
        ·
        Reply

August 19, 2026 I kept asking one question about AI agents: Who authorizes their actions?

Over the past few months, I've been building Custodyn, a runtime security platform for AI agents.

The idea came from a simple question:

Who decides whether an AI agent should be allowed to perform a real-world action?

As I was working on it, two events caught my attention.

On July 13, Anthropic published research showing that frontier AI agents could engage in behaviors such as sabotage, deception, and covert fraud under certain conditions.

A week later, on July 21, OpenAI disclosed that one of its evaluation agents escaped its testing environment and compromised parts of Hugging Face's infrastructure during an internal cybersecurity evaluation.

Those events didn't inspire the idea—but they reinforced the problem I was already trying to solve.

Most discussions around AI safety focus on prompts, jailbreaks, or model behavior. I kept coming back to a different question:

What happens at the moment an agent decides to execute an action?

Custodyn sits between an AI agent and the tools it wants to use. Before an action executes, it evaluates the request against policy and returns one of three decisions:

Allow
Block
Require human approval

Every decision is also recorded with an audit trail so teams can understand exactly what happened and why.

The Python and JavaScript SDKs are open source, while the hosted platform provides centralized policy management, approvals, and operational controls.

I'd love feedback from anyone building AI agents.

Does runtime authorization resonate with your use case?
What integrations would you expect first?
What would you want from a production-ready runtime security platform?

Website: https://custodyn.app

GitHub: https://github.com/custodyn/custodyn

custodyn

3 Likes

7 Comments

Say something nice…

Post Comment

1

The distinction between model safety and action authorization makes the problem much more concrete. The “allow, block, or human approval” boundary is a clear operational layer rather than another attempt to control the model itself.

Aryan Sinh

·
a month ago
·
Reply
1. 1
  
  That's exactly the distinction I was trying to make.
  Regardless of how capable models become, there still needs to be a deterministic decision point before an external action executes.
  My goal with Custodyn isn't to control the model's reasoning—it's to enforce policy over what the agent is actually allowed to do. That separation feels like a much cleaner security boundary than trying to solve every problem at the model layer.
  
  custodyn
  
  ·
  a month ago
  ·
  Reply
  1. 1
    
    That separation is pretty compelling. I’d be interested in hearing how you’re thinking about it as the product develops.
    What’s the best email to reach you on?
    
    Aryan Sinh
    
    ·
    a month ago
    ·
    Reply
    1. 1
      
      Thank you, I appreciate that.
      I'm still actively evolving the product, so I'd be happy to exchange ideas and hear your perspective, especially since you've clearly spent time thinking about this space.
      You can reach me at hello@custodyn.app | Looking forward to continuing the conversation.
      
      custodyn
      
      ·
      a month ago
      ·
      Reply
      1. 1
        
        Thanks! I’ve just sent it over.
        Looking forward to hearing your thoughts whenever you have a chance.
        
        Aryan Sinh
        
        ·
        a month ago
        ·
        Reply
1

Resonates strongly, we ended up building a version of this inside our own product, so answers from that experience:
Does runtime authorization resonate? It's the only layer that actually held up for us. We generate business systems that ship with MCP endpoints, so external agents can operate real customer data and we found intent-level safety (prompts, model behavior) unenforceable at that boundary. What worked was scoped tokens per entity, default-deny, a kill switch, and an audit trail that flags every AI-initiated action separately from human ones. Your allow/block/approve triad matches where we landed, with one addition worth stealing: confidence routing. Not every action is a clean allow or block - our AI steps route low-confidence outputs to a review queue rather than forcing a binary. The middle state matters.
Integrations first: MCP, before anything else - it's rapidly becoming the standard surface where agents meet tools, and a policy layer that speaks MCP natively covers every client at once. Then the obvious blast-radius tools (email send, payments, file deletion), because that's where the fear lives.
Production wants, from having run this: (1) Policy as a versioned, diffable artifact - reviewable like code, because "who changed the policy and when" is the second question after any incident. (2) A dry-run mode that logs what would have been blocked, nobody deploys default-deny cold. (3) A hard latency budget: if authorization adds noticeable delay, developers route around you, and a bypassed security layer is worse than none. (4) Approval-fatigue design, if humans get pinged constantly, approvals become rubber stamps within a week. Batching, escalation rules, and expiring grants are the difference between a control and a ritual. (5) Audit trail queryable and exportable. Ours exists as much for the customer's compliance story as for debugging.
The hardest problem we haven't fully solved, and I'd ask you the same: how do you keep the human-approval path meaningful at scale? The failure mode of every approval system in history is that the approver stops reading.

ChromolyDB

·
a month ago
·
Reply
1. 2
  
  Really appreciate you taking the time to write this. It's interesting how many of the same patterns we converged on independently.
  A lot of what you described—scoped authorization, default-deny/fail-closed enforcement, kill switch, dry-run mode, audit trails with export, and MCP support—are principles we've been building Custodyn around as well. That overlap is reassuring because it suggests these aren't theoretical concerns; they're practical requirements once agents interact with real systems.
  I particularly like your points on policy versioning and approval fatigue. I don't think the goal is for humans to approve everything forever. The goal should be for approvals to become less frequent over time as recurring decisions are encoded into policy, with approvals reserved for genuinely exceptional or high-risk actions.
  Thanks again for sharing your experience. Feedback from someone who's already been through these production challenges is incredibly valuable.
  
  custodyn
  
  ·
  a month ago
  ·
  Reply

Custodyn

About

People