Launching today
MonoCloud for Startups
One identity layer for your customers, APIs, and agents
232 followers
One identity layer for your customers, APIs, and agents
232 followers
MonoCloud is one identity layer for your customers, your APIs, and your agents. Most tools stop at a login box. We go past login into authorization and accountability: decide exactly what every user, service, and AI agent can access, prove what it did, and revoke it in an instant. Fine-grained Cedar authorization, passkeys and SSO, API protection, M2M, and mTLS with certificate-bound trust, all on one platform. Startups get the full platform free for one year.
the instant-revoke plus proof-of-what-it-did combo is the part that actually matters once agents are calling real APIs on someone's behalf. most identity providers treat agents like just another OAuth client and call it done. does the audit trail capture the actual reasoning/prompt context behind an action too, or just the API call itself? that distinction matters a lot when you're trying to explain after the fact why an agent did something unexpected.
@omri_ben_shoham1 We audit the identity layer, and it's fairly detailed, the principal that acted, the mTLS and trust store context, and the policy evaluation itself, including whether the decision was allow or deny and why, for example a revoked certificate. What it doesn't capture is the model's prompt or reasoning, and that belongs in your agent or observability layer. You join the two by the agent's identity to explain why it acted.
Interesting that mTLS with certificate-bound tokens is a first-class thing here rather than an enterprise add-on. Most CIAM tools treat that as an afterthought. What's the story for revocation latency — how fast does a revoked cert actually stop working in practice?
@maurya_abhiranjan Revocation is checked live at validation time, before a client can get or use another token, not left until the token expires. You've got live OCSP for status, CRLs, and a local deny list to block a cert outright. How fast it actually takes effect comes down to the cache windows you control on the trust store, OCSP status is cached five minutes by default and CRLs fifteen, and you can tighten those toward near-instant. The full set of mTLS validation and revocation settings is laid out here if you want it, monocloud.com/features/mtls
Congrats on the launch. The customer/API/agent identity angle is timely because agent access can blur normal user boundaries. How do teams inspect which identity performed an action, which permissions were used, and whether the action came from a human or an agent?
@yaroslav_stelmakh Good question, and it's a real gap most setups have. Every token request is audited with the acting principal, the trust store and certificate context for mTLS, and the policy evaluation itself, so you can see who acted and whether it was allowed. Human versus agent is built into the model rather than guessed, clients carry a type of either application or agent, and machine-to-machine requests carry no user in the request, so an agent action looks structurally different from a human one. The permissions side is the Cedar decision that gets logged with the request. The client-type and context details are here if you want them, monocloud.com/docs/guides/api-access-policy
I like the emphasis on authorization over authentication. How opinionated is MonoCloud about application architecture? Could a team adopt just the Cedar authorization layer while keeping their existing auth provider, or is the biggest value unlocked by using the full identity stack?
@tarqiya_forgah Not very opinionated, it's standard OAuth and OIDC with drop-in SDKs, so you adopt it piece by piece rather than rewriting your app. On the Cedar part, to be precise, the authorization policies are evaluated at the moment MonoCloud issues the access token, so the authz layer and token issuance go together. The full value shows up when MonoCloud is in the token path for the APIs you want to govern. If you're thinking of running only the policy layer on top of a different auth provider, I'd love to get into your exact setup.
Is the SPIFFE workload identity tied to a specific runtime, or does it work across mixed environments (some services on Kubernetes, some on bare VMs)? Trying to figure out how much of my setup I'd have to standardize.
@suyash_kr Not tied to a runtime, it's SPIFFE-based, so anything with a valid SVID works, whether it's a Kubernetes pod or a workload on a VM. If they share a trust domain one trust store covers both, and if they're separate domains it's one trust store each. The setup walkthrough is here if it helps, monocloud.com/docs/guides/workload-identity
MonoCloud for Startups
Hey Product Hunt 👋 Vishal here, founder of MonoCloud.
Every company is racing to put AI agents into production. Almost none of them can answer one simple question. When an agent does something it should not, who is accountable?
The log will say an agent did it. But an agent has no intent. Someone gave it that access, and today most teams cannot say who, cannot prove it, and cannot pull it back fast. That gap is the biggest unsolved problem in identity right now, and it is why I built MonoCloud.
I have built authentication into products four times over my career. Every time, the login box took a weekend and everything that mattered took months. Passkeys alone were over 800 engineering hours before they were production ready. I learned the hard way that identity is not a feature you bolt on. It is infrastructure, and it decides whether you can be trusted.
MonoCloud is that infrastructure. One platform for your customers, your APIs, and your agents, where you decide exactly what each can access, prove what it did, and revoke it in an instant.
Two convictions shaped it, and I still stand by both:
🔹 Build on open standards, not shortcuts. Authorization runs on Cedar, workload identity on SPIFFE, and trust on mTLS with certificate-bound tokens. Anyone can demo a policy dashboard. Far fewer hold up in a real security review.
🔹 Treat agents as first-class identities from day one. Every agent gets a scoped identity, acts on behalf of a user only within the limits you set, and leaves an audit trail you can revoke in one click.
All of it is live today. Ten design partners across SaaS and AI companies are building on it now.
👉 Startups get the full platform free for one year, every premium feature, no gates. Apply here: MonoCloud for Startups - Free for One Year 👈
If identity is core to what you are building, we are opening a few more design partner spots. Leave a comment or reach me on LinkedIn.
I will be here all day. The one thing I want to hear is this. How are you handling identity for your agents today, and what happens the first time one does something it should not?
Identity layer that covers customers, APIs AND agents in one place is actually pretty rare. Most solutions handles only one or two of those well. Free for a year is generous, what happens at the end?