u/Cerbosdev

hey everyone. most mcp threads are about what these servers can do. the security side is the opposite question, every server you connect is a third-party dependency with a path to production, added with near-zero friction, usually with no review and no owner. that's a supply chain surface, and it's growing fast. my colleagues and i wrote it up longer as a blog, but everything useful is in this post, sharing in case it's handy for the community.

first, why these are actually risky. you don't even have to call a tool to get burned. Trail of Bits showed a malicious server can hide instructions in its tool descriptions, and those reach the model as soon as your client loads the tool list, so connecting it is the exposure. then there's the over-scoped credential pattern. Invariant Labs showed a poisoned github issue coercing an agent into leaking private-repo data over the same token, and Simon Willison wrote up a Supabase case where a service role bypassed row-level security while reading attacker-controlled content. and valid auth is not authorization, which is how Asana's mcp-connected ai feature exposed data across tenants. the credential was valid but nobody checked whether that user should see that specific record. OWASP has a Top 10 for agentic apps now if you want the taxonomy behind all this.

here's what to check, roughly in order:

1. inventory and ownership. can you produce a current list of every mcp server connected to your systems, each with a named human owner. ideally a server has to be registered before it's allowed to make any call, so unknown ones get blocked rather than discovered later. discovery is the prerequisite for everything else.

2. identity and least privilege. each server and agent gets its own identity, not a shared secret. scope its creds to the minimum it needs, keep them short-lived, and never hand it a broad role that bypasses your data layer's own controls.

3. tool surface. know exactly which tools a server exposes, and actually read the tool descriptions, since that's where injected instructions hide. show each agent only the tools it needs, not the full catalog. a tool an agent can't see is one it can't be talked into using.

4. authorization enforcement. put an authz decision outside the server, checked before a tool runs, that looks at the agent, the user it's acting for, the tool, and the arguments. fail closed, so no explicit allow means deny. this is the one control that holds even when the server is third-party and you can't see its code.

5. downstream reach. know what the server can actually touch once a call succeeds, and make sure it respects your underlying data controls instead of bypassing them. for rag and retrieval paths, filter by the user's real permissions, not the agent's.

6. audit evidence. you should be able to pull a record of every action a given server or agent took, with the policy that allowed or denied each call. if an incident review asks what a third-party server's agent did last tuesday, that should be a query, not an archaeology project.

7. lifecycle and revocation. you should be able to narrow or cut a server's access without redeploying anything, and access should expire or get reviewed rather than living forever. graduated beats binary, so you can scope it down the moment it worries you while legit work keeps running.

what saves most grief : vetting and enforcement are two different jobs. vetting tells you what you connected. enforcement, that authz check outside the server that fails closed, is what keeps it bounded no matter how much you trust the code. the strongest controls are the ones that don't assume the server is trustworthy, because the servers you control least are the ones most likely to bite you.

full disclosure, i work at Cerbos and we do authorization, so items 4, 6 and 7 are squarely the kind of thing we build, if you need it. but 1 through 3 are yours to own regardless of tooling, and a checklist doesn't enforce anything by itself. none of this replaces reviewing servers yourself before they hit prod :)

hey all. I work at Cerbos (we do authorization), so we spend a lot of time with security leaders, at identity events like Gartner IAM, Identiverse and EIC, and in the breach and enforcement data. Our CPO Alex Olivier, who co-chairs the OpenID AuthZEN authorization standard, pulled all our insights into a maturity model for authoirzation. 

the piece I think is most useful to actually run yourself is the self-assessment, so I'm sharing the whole thing here.

You answer 15 questions about how your authorization program actually runs in production, not how the documentation says it runs. Count your confident yeses, soft yeses don't count, and that number maps to a stage. The honest version usually puts most programs a stage below where their compliance docs would. That gap is actually the useful part!

Takes about an hour with your team, ideally with someone from engineering in the room since they know where the bodies are buried. here are all 15, grouped into 5 categories.

A. Coverage and ownership
Can one person, within an hour, produce a complete list of every service in production that enforces authorization, and describe how each one does it?
Is there a single team accountable for the authorization layer across the company, with a named leader who can be held to outcomes?
Does your CISO get a regular report on authorization posture, the same way they get one on vulnerability posture?

B. Policy and evidence
Are authorization policies stored in a version-controlled repo with code review, test coverage, and an audit history?
When a policy changes, is there a decision log showing what was different about the decisions made before and after the change?
Can you produce, on demand, a report showing every access decision made by a specific identity over the last 90 days?

C. Runtime behavior
Are authorization decisions re-evaluated during long-running sessions, or only at login?
Do decisions use context beyond role, like resource sensitivity, time of day, device state, or location?
If a user's risk signal changes mid-session, does authorization respond without a full logout or session reset?

D. Non-human identities
Do service accounts, workloads, and AI agents go through the same policy model as human users?
Can you list every AI agent or autonomous workload in production today, what it's allowed to do, and who owns it?
When a non-human identity's scope changes, is there a review step, and is it documented?

E. Response and governance
Can you revoke an identity's access to every system in under five minutes, and prove the revocation took effect?
Is authorization coverage one of the metrics your board sees each quarter?
Do post-event analytics feed back into policy on a defined cadence, rather than only after an incident?

scoring is just your count of confident yeses out of 15.
0 to 3, Stage 1, ad-hoc.
4 to 7, Stage 2, documented.
8 to 11, Stage 3, centralized.
12 to 15, Stage 4, governed.

For what it's worth, most serious B2B SaaS programs we see land at Stage 2 with a couple of Stage 3 answers, usually in policy and evidence or response and governance. If that's you, you're the median, not behind.

The full ebook (maturity model i was mentioning earlier) has these same questions plus what each stage means for your regulatory exposure and a 90-day plan to move up. let me know if you want it, happy to share in comments if there is interest.

Either way, curious where people land, and whether the number matched your gut or came out lower

Quick disclosure first, I work at Cerbos (we do authorization). Our CPO Alex Olivier, who co-chairs the OpenID AuthZEN standard, built an authorization maturity model from what we see across security teams, identity events, and breach data. Part of it is a 15-question self-assessment, and running it with teams keeps surfacing the same specific question, which is what I actually want to ask here.

The assessment first, since my question won't actually make sense without it,. You answer each one honestly about how your program runs in production, not how the docs say it runs, count your confident yeses, and that maps to a maturity stage:

A. Coverage and ownership
Can one person, within an hour, produce a complete list of every service in production that enforces authorization, and describe how each one does it?
Is there a single team accountable for the authorization layer across the company, with a named leader who can be held to outcomes?
Does your CISO get a regular report on authorization posture, the same way they get one on vulnerability posture?

B. Policy and evidence
Are authorization policies stored in a version-controlled repo with code review, test coverage, and an audit history?
When a policy changes, is there a decision log showing what was different about the decisions made before and after the change?
Can you produce, on demand, a report showing every access decision made by a specific identity over the last 90 days?

C. Runtime behavior
Are authorization decisions re-evaluated during long-running sessions, or only at login?
Do decisions use context beyond role, like resource sensitivity, time of day, device state, or location?
If a user's risk signal changes mid-session, does authorization respond without a full logout or session reset?

D. Non-human identities
Do service accounts, workloads, and AI agents go through the same policy model as human users?
Can you list every AI agent or autonomous workload in production today, what it's allowed to do, and who owns it?
When a non-human identity's scope changes, is there a review step, and is it documented?

E. Response and governance
Can you revoke an identity's access to every system in under five minutes, and prove the revocation took effect?
Is authorization coverage one of the metrics your board sees each quarter?
Do post-event analytics feed back into policy on a defined cadence, rather than only after an incident?

Scoring is your count of confident yeses out of 15. 0 to 3 is ad-hoc, 4 to 7 documented, 8 to 11 centralized, 12 to 15 governed.

Now the actual question: the three that tend to be hardest to get a provable yes on are sub-five-minute revocation across every system, mid-session re-evaluation when a risk signal changes, and a live inventory of every AI agent in production. 

For anyone who has gotten a genuine, provable yes on those, how did you do it in practice? Specifically, what is enforcing the sub-five-minute revocation across heterogeneous systems (token TTLs, a central PDP, something else), and what are you using to re-evaluate authorization mid-session without a re-login?

Happy to drop the full write-up with the scoring bands and what each stage means for regulatory exposure in the comments if anyone wants it.