Orchestrators create agents at runtime, and tool servers hand them every key you own. Chancery gives each agent its own identity, access that can only narrow, safe runtime spawning, verified tool servers, instant revocation, and a provable audit trail.
No reviews yetBe the first to leave a review for Chancery
Maker
📌
Hey Product Hunt 👋
Agents stopped being single scripts and became fleets. Orchestrators create sub-agents at runtime, each alive for minutes, each wired into real systems. Almost nothing governs them. One API key shared by everything, all-or-nothing tool access, server code downloaded fresh on every launch, and the only record of what happened written by the agent itself.
Chancery is the identity layer for that. Following one agent's life:
Identity. Registered, owned by a named human, and fingerprinted (prompt, config, tool list), so "did this change since review?" becomes a comparison rather than a meeting. The agent, its version, and each running copy are separately revocable.
Access that only narrows. Permissions are signed and delegated downward, and a child can only hold a subset. Revoke any link and everything beneath it dies on its next action. Widening simply cannot be expressed.
Safe runtime spawning. This is the multi-agent piece most stacks skip. A human approves a template once, capping capability and lifetime. Orchestrators then create workers on the fly with no admin credentials: each gets its own identity, a narrower slice of the parent's access, the parent's owner attached so accountability can't be laundered, and an expiry that shuts it out automatically.
Both directions secured. Requests are checked live, and anything an agent can't do is hidden from the model rather than refused. The tool server is fingerprinted and re-verified before every run. Change one file in its dependencies and it won't start. You can also install servers frozen instead of pulling them fresh, restrict them to named destinations, make their filesystem read-only, and run them as a separate user.
Secrets agents never hold. Encrypted at rest and handed only to the tool server as it starts, so a prompt injection can't leak what was never in context. Rotation is one update with no agent changes. Browser agents work the same way: a human's session is custodied on their behalf, and every page the agent visits is checked against what it's allowed to reach.
Revocation that lands. Cut access and the next action fails, mid-session. Servers that opt in can check with Chancery right before committing, so a revocation arriving mid-flight prevents the action instead of documenting it afterwards. That part needs the server to cooperate, and the docs say so.
Evidence, not logs. Tamper-evident, so any edit or reorder is detectable, and physically unable to hold prompts or payloads. There's also a read-only dashboard with a live timeline and the delegation chain drawn as a tree.
Adoption is a one-line change to how you already launch tool servers. It governs non-MCP agents too (LangGraph, CrewAI, cron jobs) through the same decision API.
All 17 known limitations are published with owners and timelines. Last week someone on Reddit showed that one of our credential-isolation claims was weaker than stated. He was right. It's now a numbered gap with his handle on it, and the fix shipped the next day.
Apache-2.0, self-hosted, no cloud, no telemetry. brew install chanceryhq/tap/chancery
More useful than an upvote: tell me where it breaks.
🔗 chanceryai.vercel.app
⭐ github.com/chanceryhq/chancery
Report
Identity is becoming a much bigger problem for AI agents than for traditional apps. Curious what part of that problem you believe is still most underestimated.
Report
Maker
@aryan787544 the underestimated would the callee side. Everyone is busy giving the agent an identity, but the tool it calls is usually unsigned code running with your keys in its environment. You can scope the agent perfectly and still hand everything to a poisoned dependency. That's why Chancery pin tool servers to exact digests and inject credentials server side so the agent never holds them.
Report
@anee769 That's a really interesting way to frame it. It suggests the identity problem isn't just "who is the agent?" but "can every dependency in the execution chain be trusted?" I'll be curious whether, over time, people think about Chancery as an identity layer or as the system that makes AI execution auditable end-to-end. Those feel like very different categories.
Report
Maker
@aryan787544 I'd push back on them being different categories at all. Identity without enforcement is just labels, and audit without identity is just logs you can't trust. They only work as one thing: every action carries who did it, what they were allowed to do, and what code actually ran, checked in the execution path itself. Chancery treats that as a single security property, not a stack of separate products.
Report
@anee769 That's a helpful distinction, and I think I understand the thesis much better now.
Treating identity and audit as a single security property instead of separate product categories is a much stronger framing than I initially assumed.
I've got a couple of thoughts on how that framing could influence positioning as AI infrastructure matures. What's the best email to send them to?
Report
A nice dashboard showing each agent's real-time permissions tree would be super helpful. Something where you can see what tools an agent currently has access to and visually tighten or revoke scopes with one click. Right now the audit trail sounds great after the fact, but I'd love a live view to catch drift before it becomes a problem.
Report
Maker
@mer1045076 the dashboard ships today: run chancery serve and open /ui, and you get the live audit timeline with a permanent integrity badge, the agent roster, and each writ's delegation chain drawn as an actual tree. "see what an agent currently has access to" and "watch it live" both exist right now. It's a read-only dashboard for security.
Report
A sandbox mode for testing agents before they get real credentials would be huge, especially for evaluating how narrowly they scope access in practice. Maybe a one click "dry run" that simulates the full identity and tool flow but uses throwaway keys, so you can audit behavior safely before going live.
Report
Maker
@boran0uq6 half of this exists today. Wrap has a dry run that runs the full identity and policy flow, shows exactly what the agent would be allowed to call and what gets denied, and spawns nothing. Fastest way to see how narrowly an agent is scoped before it goes live.
The throwaway keys part is the gap. Right now you'd point it at a test server with fake secrets yourself. An sandbox identity with auto generated dummy creds is a genuinely good idea, adding it to the roadmap. Thanks for this.
Identity is becoming a much bigger problem for AI agents than for traditional apps. Curious what part of that problem you believe is still most underestimated.
@aryan787544 the underestimated would the callee side. Everyone is busy giving the agent an identity, but the tool it calls is usually unsigned code running with your keys in its environment. You can scope the agent perfectly and still hand everything to a poisoned dependency. That's why Chancery pin tool servers to exact digests and inject credentials server side so the agent never holds them.
@anee769 That's a really interesting way to frame it. It suggests the identity problem isn't just "who is the agent?" but "can every dependency in the execution chain be trusted?" I'll be curious whether, over time, people think about Chancery as an identity layer or as the system that makes AI execution auditable end-to-end. Those feel like very different categories.
@aryan787544 I'd push back on them being different categories at all. Identity without enforcement is just labels, and audit without identity is just logs you can't trust. They only work as one thing: every action carries who did it, what they were allowed to do, and what code actually ran, checked in the execution path itself. Chancery treats that as a single security property, not a stack of separate products.
@anee769 That's a helpful distinction, and I think I understand the thesis much better now.
Treating identity and audit as a single security property instead of separate product categories is a much stronger framing than I initially assumed.
I've got a couple of thoughts on how that framing could influence positioning as AI infrastructure matures. What's the best email to send them to?
A nice dashboard showing each agent's real-time permissions tree would be super helpful. Something where you can see what tools an agent currently has access to and visually tighten or revoke scopes with one click. Right now the audit trail sounds great after the fact, but I'd love a live view to catch drift before it becomes a problem.
@mer1045076 the dashboard ships today: run chancery serve and open /ui, and you get the live audit timeline with a permanent integrity badge, the agent roster, and each writ's delegation chain drawn as an actual tree. "see what an agent currently has access to" and "watch it live" both exist right now. It's a read-only dashboard for security.
A sandbox mode for testing agents before they get real credentials would be huge, especially for evaluating how narrowly they scope access in practice. Maybe a one click "dry run" that simulates the full identity and tool flow but uses throwaway keys, so you can audit behavior safely before going live.
@boran0uq6 half of this exists today. Wrap has a dry run that runs the full identity and policy flow, shows exactly what the agent would be allowed to call and what gets denied, and spawns nothing. Fastest way to see how narrowly an agent is scoped before it goes live.
The throwaway keys part is the gap. Right now you'd point it at a test server with fake secrets yourself. An sandbox identity with auto generated dummy creds is a genuinely good idea, adding it to the roadmap. Thanks for this.