There's a real gap identified (execution permission instead of output guardrails). The timing concern is valid (we're scaling agent framework way faster than security infrastructure — see Clawdbot-Moltbot). The default-deny + time-boxed permissions + audit logs is a solid model, easy to discuss at high-level with security teams in an org. The "Auth0 for AI Agents" framing is clear and positions it well.
Actually, the audit log piece is really huge. Having a complete execution trace with authorization decisions is invaluable for incident response. That alone might justify adoption even if the blocking mechanism is imperfect.
My concerns and questions:
- Where exactly does this sit? If it's between the agent and tool calls, that's relatively straightforward. If it needs to intercept arbitrary code execution or API calls, that's significantly harder.
- Adding another authorization layer means more setup, more policy configuration, more potential points of failure. Adoption challenge.
- Who defines what's "allowed"? In what format? How granular? Actually expressing "this agent can do X in context Y at time Z" in a way that's both powerful and usable, that's the whole ballgame (IMHO). I have in mind how complex AWS IAM policies got, and those are for relatively static systems. AI agents are dynamic, context-dependent, and probabilistic.
- By the time Reg sees a request to execute, the LLM has already decided. What happens when you block it? Does the agent gracefully handle denials and retry with different approaches?
I'd be interested in seeing real-world policy examples from your design partners. That'll tell you whether you've found the right abstraction layer.
Congratulations for just framing the idea and getting this far. Being very concerned about the current free-wheeling AI expansion with minimal security, I strongly believe this is going in the right direction and would like to know where this leads.
> Where exactly does this sit?
Between agent reasoning and tool execution. The agent/framework calls Reg.Run before executing any tool/action. The Pattern would be:
1. Agent decides: "I should refund $250" 2. Calls Authorization Protocol/authorize with action details 3. Reg.Run evaluates policy → approved/denied/requires_approval 4. If approved, agent proceeds. If denied, agent knows immediately.
Integration points: LangChain/LangGraph tools, MCP servers, custom agent frameworks. We provide middleware that wraps tool calls.
> Adoption challenge (more setup, more config)
Valid concern tbh - I think this was the most difficult part of thinking about Reg.. Specially because I didn't know where to start. After speaking with Engineers and friends I came to this:
- Start with sane defaults (deny-all, then allowlist incrementally) - Pre-built policies for common patterns (refunds, data access, transfers) - Dashboard UI for ops teams (no code/policy language needed) - Gradual rollout: monitor-only mode first, then enforce
I would like to do adoption easier, with a good UX, not just spec.
> Who defines what's "allowed"?
Great question, Trying to llearn this with design partners right now.
My current thoughts/ approach: Three-tier system - Simple rules (amount thresholds, time windows) → YAML config - Business context (customer LTV, fraud flags) → external data lookups - Complex logic → delegate to approval workflow
You're right that AWS IAM got unwieldy. We're trying to avoid that by: 1. Keeping policies human-readable (ops teams, not just engineers) 2. Starting simple, adding complexity only when needed 3. Approval workflows as escape hatch (when policy can't decide)
The abstraction I'm testing: "auto-approve simple cases, require human judgment for edge cases, deny obviously bad things." Keeping it fairly simple and evolve from there.
Thank you so much for reading, giving feedback - and most importantly - making my think!