MonoCloud for Startups
One identity layer for your customers, APIs, and agents
Start new thread

MonoCloud for Startups - One identity layer for your customers, APIs, and agents

by
•
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.

Add a comment

Replies

Best

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.

Maker

 Thanks, that was a deliberate choice. Certificate-bound tokens make a stolen token useless without the key, and that shouldn't be something you only get once you're big enough for an enterprise tier. The free year for startups includes it, so early teams can build on cert-bound trust from the start instead of retrofitting it later.

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?

Maker

 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,

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.

Maker
Fair question and honestly the one we thought hardest about. After the year, startups move to the plans. The goal is that by then you're paying because the product earned it, not because migration is painful. If the jump ever feels steep for a team, we'd rather talk than lose them, so reach out before the year ends and we'll figure it out.

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.

Maker
That's the exact sentence we want people saying a year from now. Cobbling five tools together is where most identity bugs are born, the seams between tools are where things fall through. Thanks Fatma.

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?

Maker

 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.

As someone who built auth from scratch on Cognito (custom role injection, multi-tenant org isolation, MFA, OAuth flows) — I have strong feelings about this space. The pain is real, especially for startups that underestimate auth complexity on day 1. What's your migration story like for founders already locked into Cognito or Auth0?

Maker

 You clearly know the depth here, custom roles and multi-tenant isolation on Cognito is exactly what people underestimate on day one. The good news is you don't rip and replace. It's standard OAuth and OIDC, so MonoCloud runs alongside what you have and you move one surface at a time, and you bring your users across programmatically through our Create User endpoint, carrying their claims plus private and public data so their properties come over from Cognito.

Honestly I'd point you to our startup program. You get the full platform free for a whole year with all the premium features, and our team will be hands-on with the migration so we can help wherever you get stuck. Past that, you get to focus on building your product instead of auth and identity. You can fill out the form here,

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.

Maker

 Fair question, and the right one to ask about anything as sticky as identity. There's no cliff. When the free year ends you move onto our standard published plans, not into an enterprise sales conversation, so it's a predictable, self-serve scale-up rather than a renegotiation. We kept the step up gradual on purpose, because a team that grew on us for a year and then churned over sticker shock would mean we got pricing wrong. If the jump ever looks steep for where you are, reach out before the year's up and we'll sort it out. The whole point of the free year is to take pricing off the table as a reason to ever leave something this core.

 predictable self-serve scale-up is the right answer, and saying it out loud (rather than leaving it as a sales-team surprise later) is what actually removes the fear. the 'reach out before the year's up' safety valve is a nice touch too - it means the free year is a real onboarding gift, not a bait-and-switch clock. appreciate the straight answer.

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?

Maker
Thanks Abdurrahman, and you're right that most tools pick one lane. Customer identity, API auth, and agent identity share the same underlying primitives, so splitting them across three tools always felt like the wrong default to us. On the free year: after it ends, startups move to our paid plans. We kept the jump deliberate and gradual because a team that grew with us for a year churning over sticker shock would mean we failed at pricing, not them. If it ever feels steep, reach out before the year ends and we'll figure it out.

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.

Maker

 Exactly this. The one all-powerful key is where almost everyone starts because it ships fastest, and it stays invisible right up until the second automated process has to share it. Scoped identity per agent plus revocation you can actually trigger is what makes delegating feel safe instead of just hoping. Well put.

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?

Maker

 Sharp catch. Classic step-up does assume a human is there to re-verify, so re-prompting a fully autonomous agent for a passkey doesn't make sense. Two things cover the agent case instead. When a human should sign off, you use human-in-the-loop consent, pausing the agent before the sensitive action and requiring a fresh approval. When it's genuinely autonomous with no human, you don't step up at all, you gate the action with policy, a Cedar rule that decides whether that agent, with that scope, is even allowed to trigger the payment, rather than re-verifying someone who isn't there.

First
Previous
123
Next