MonoCloud for Startups

One identity layer for your customers, APIs, and agents

SaaS

Developer Tools

Security

Visit WebsiteSee on Product Hunt

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.

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.

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?

Everything in the thread assumes a human kicked the agent off. A good chunk of what I run is on a cron, hourly, nobody logged in, so there is no session to ride along as context.user, and that is exactly where "on behalf of" gets slippery: the agent is acting for an intent someone wrote down three weeks ago, not for a person who is awake to notice. Does that shape get its own principal, or does it collapse into a machine client with a service identity and you lose the delegation trail?

First of all a great congrats to @riya_pariyar @roguetink @maganuk
I am just curious that you've said you're building the auth layer for agentic products "from the ground up" instead of bolting agent support onto human auth. Concretely, what does a token look like when an agent calls another agent three steps downstream? How do you actually scope and audit that so the blast radius doesn't become "every permission that token ever carried"?

Vishal — the step-up-before-high-risk-action line caught me. If an AI agent, not a human at a keyboard, is the one about to trigger something like a payment or a live bid submission, can step-up auth even work — or does that whole model assume there's a human around to re-verify?

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?

the one year free offer for startups is honestly such a smart move, basically lets you build the whole stack without cobbling together five different auth tools.

How does pricing work after year one? Curious if startups that grow during the free period end up sticking or if the jump to paid feels steep.

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?

honestly the one free year for startups is kind of a big deal, but what really stands out is the mTLS with certificate-bound trust. most platforms treat that as an enterprise add-on and bury it in pricing. shipping it on day one for early teams shows you actually thought about the security stack instead of bolting it on later.

This is the unglamorous part that makes agent work production-safe. Small teams often start with one all-powerful service key because it ships fastest, then the second or third automated process turns that shortcut into real operational risk. Per-agent identity plus fast revocation is the boring layer that lets you delegate without pretending the risk disappeared.

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?

the agent-as-a-separate-identity model is the right architecture, and Cedar for token-issuance policy is a solid choice over roles that stop scaling. the question I didn't see answered yet is the business side of the free year: what does year two actually look like pricing-wise for a startup that's grown into real usage by then, is it a predictable seat/request-based scale-up or more of a cliff where the free tier suddenly becomes an enterprise sales conversation? that's usually the thing that decides whether teams migrate off something core like identity later out of pricing fear rather than product fit.

Amazing, the product looks so good, the tiers are so generous, so excited to try it out 🥳

Congrats on the launch - it's an impressive offering!
I'm curious how MonoCloud tracks the agent acting on behalf of the user - is the agent treated as a separate identity?
And can I use Cedar to manage access to application-level entities? How does that work in practice?

I'm currently using Clerk, whose separation between development and production environments makes it easy to copy the configuration to production when launching. Do you offer a similar workflow or support migrations from other authentication providers?

Congrats on the launch identity is one of those problems that only looks simple until you have to build it yourself Really Building authentication and identity is never as straightforward as it seems Excited to see products taking a fresh approach here Congratulations to the team and hope you have a fantastic launch

The agent-on-behalf-of-user piece is what most auth stacks punt on, so going straight at it with Cedar is the right call. Concretely: when an AI agent acts for a user, is its access always a downscoped subset of that user's own permissions (so it can never exceed what the human could do), and can you express that delegation in a single Cedar policy? And if you revoke mid-task, does an already-issued agent token stop on the next call or only at expiry?