MonoCloud for Startups
One identity layer for your customers, APIs, and agents
439 followers
One identity layer for your customers, APIs, and agents
439 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.
MonoCloud for Startups
@thys_beesman You are right that it is already the wrong shape. A single service role key with full reach is where almost everyone starts, so you are in good company.
The second process is where it really starts to hurt. Once a billing job and an enrichment job are sharing one credential, a leak means you cannot even tell which one did what, and you end up rotating the key on both.
The way we think about it, each process should get its own scoped identity instead of everyone leaning on one key. You give that identity a policy for what it is allowed to do, so the enrichment worker can only enrich and the billing worker can only touch billing. If one of them is ever compromised, you revoke just that identity without taking the others down, and every action is logged against that specific agent instead of getting lost in generic DB logs.
I am curious, are these long-running services or short-lived jobs, and where do they run, somewhere like Kubernetes, Fly, or Railway? That is what will decide whether workload identity with SPIFFE or short-lived machine-to-machine tokens is the cleaner path for you.
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?
MonoCloud for Startups
@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?
MonoCloud for Startups
@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?
MonoCloud for Startups
@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.
MonoCloud for Startups
@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
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.
MonoCloud for Startups
@kervangamz80440 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.
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.
MonoCloud for Startups