The asterisk that grants everything

You said no MCP. That was a statement of intent. The cloud environment does not read intent. It reads policy. An identity can invoke any action an attached policy permits, regardless of what was agreed in a meeting or written in a design document. If the policy permits the action, the action is available to whoever holds the identity. A denial that lives only in conversation is not a denial the system will enforce. The environment enforces the effective policy and nothing else.

The distance between what you said and what the policy allows is the exposure. Over-permissive policies widen that distance in the attacker’s favor. When a role carries wildcard actions or wildcard resource scope, the set of operations it can perform is larger than the set anyone intended it to perform. That difference does not appear in the org chart or in the project brief. It appears in the policy document and in the requests the system returns as successful. The identity does not need to escalate in the classic sense. It uses what it was already granted.

Hold the position plainly. Identity is the boundary. If the identity can reach the capability, the capability is in scope. That is confirmed by the grant itself. The name you gave the environment, the assurance you offered in the review, the line item that said this access was out of bounds, none of that changes the evaluation the policy engine performs. Controls that are not enforced are not controls. A restriction that was stated but never written into policy is not a restriction. It is a preference the system is free to ignore, and it will.

What failed is observable without interpretation. The access control approved a request it was expected to deny. An identity presented credentials or assumed a role, submitted an API call, and the call returned success. The action completed and produced its result. That is the externally observable behavior. The enforcement point did not interrupt the request, did not return an authorization error, and did not route the call to a deny. From outside the system, the only signals are the successful response and whatever the action changed or exposed. Whether that event was captured in logs is not confirmed unless stated.

No boundary was crossed by force. That distinction matters for how you respond. The request was inside the permitted set the entire time. The system behaved exactly as its policy instructed it to behave. There was no exploit of a flaw in the platform, no bypass of the evaluation engine, no defect in how the request was processed. The request was evaluated and it matched an allow. The observable failure is narrow and specific: the policy permitted an action that the stated scope said should not be reachable, and the enforcement point held no rule that corresponded to the denial you declared.

State it without softening. The control that was supposed to represent no MCP did not exist at the enforcement layer. Something was expected to stop the action. Nothing did. If a control does not stop the behavior it was named to stop, the control is ineffective. Here there was no control to rate as ineffective, because the denial was never instantiated as one. The gap was not partial coverage. The gap was absence, observed as a request that should have been blocked and was not.

It failed because the effective policy was over-permissive and the denial was never written where the system could read it. The enforcement point evaluates each request against the policy that is actually attached to the principal, not against intent, not against documentation, not against the assurance given in a meeting. When the effective policy contains an allow that matches the request, the request is permitted. There is no secondary pass that checks for we said no. Wildcard actions, broad resource scope, and role assumption chains expand the allow set until it covers operations no one deliberately authorized. The policy did precisely what it was written to do. It allowed what it was written to allow.

The denial lived in a location the policy engine never consults. Meeting notes, a chat message, an architecture diagram, a verbal agreement in review. None of those are enforcement points. The only enforcement point is policy evaluation. If no MCP was never expressed as an explicit deny, or as the deliberate absence of any allow that would reach it, then it was never enforced for a single request. The system did not fail to honor the restriction. The restriction was never present in the one place that decides. Absence of an enforced deny is not the same as a deny. Treat the two as identical and you will keep misreading the exposure.

Trust here was granted once and not revalidated. Broad permissions persist until someone actively narrows them. Nothing in the environment expires a grant because the intent behind it changed. Automation compounds this: the same over-broad grant is applied at scale to every principal that inherits the role or the policy, and each one carries the full reach of the original grant. The design assumed the stated restriction and the enforced restriction were the same thing. They were not. What you said was a control. What the policy contained was the control. Only one of them was evaluated, and it was not the one you said.

The mechanism is single-step. A principal holds an identity. The identity has an effective policy, which is the union of every allow attached to it directly, through group, through assumed role, through inherited policy. A request arrives. The evaluation engine compares the request against that union. If any statement matches the action and the resource, and no explicit deny overrides it, the engine returns allow. The request executes. There is no additional gate. “No MCP” was not a statement in that union, so it was not consulted.

Wildcard actions collapse the distance between one permitted action and every action the service exposes. A wildcard on actions means every operation the service offers is inside the allow set. A wildcard on resource scope means every object of that type is reachable. When both are present, the effective reach of the identity is the full surface of the service, bounded only by what the platform provides, not by what the design intended. The stated restriction sat outside this evaluation entirely.

Role assumption extends the same union. When an identity can assume a role, it inherits that role’s effective policy for the duration of the session. The reachable set is not the identity’s own grants. It is the transitive closure of every role it can reach and every grant those roles carry. Each assumption is a legitimate operation the policy permits. The chain is not a bypass. It is the policy resolving to exactly what it contains.

Automation applies this union to every principal that inherits it. Whether a specific number of principals inherited the grant is not confirmed. What is confirmed is the mechanism. A broad grant attached to a role or a policy is carried in full by everything bound to it. The grant does not shrink as it propagates. The over-permissive allow becomes the standing capability of every identity that holds it, with no second decision point.

The pattern is that stated intent and effective policy are two different objects, and only one is evaluated. Any restriction expressed in a location the evaluation engine does not read has no force. The location does not change that. Meeting, diagram, review comment, ticket, naming convention. If it is not an explicit deny or the deliberate absence of any allow that reaches the action, it does not participate in the decision. This is not specific to MCP. It is the general shape of any control that was declared and never instantiated.

The exposure is the gap between the two objects. The wider the allow set relative to the intended set, the larger the number of operations available that no one deliberately authorized. Wildcards and assumption chains widen that gap by construction. The gap is not visible in intent. It is visible in the effective policy and in the requests that return success. An operator who reviews intent sees the restriction. An operator who reviews the effective policy sees whether the restriction exists. Only the second review reflects what the system will do.

The same mechanism produces the same result for every declared but unenforced boundary in the environment. A service account described as read-only that carries a write action is write-capable. A role described as scoped to one resource that carries a wildcard resource is scoped to all of them. A principal described as having no path to a capability that can assume a role carrying it has the path. In each case the words describe one boundary and the policy enforces another. The pattern holds wherever the description and the grant were never reconciled.

Hold the operator position. The environment enforces the effective policy and nothing else. That is not a failure mode to be tuned. It is the operating condition of the system. Any assurance that depends on the system reading intent is an assurance the system cannot honor, because it was never built to consult intent. Treat every stated restriction as absent until it is confirmed present in policy, as an explicit deny or as the absence of any allow that reaches the action.

What must now be true is narrow. The denial named no MCP exists at the enforcement point or it does not exist. For it to exist, the effective policy of every principal in scope contains no allow that reaches the action, or contains an explicit deny that overrides any allow that does. Wildcard actions and wildcard resource scope reach the action until proven otherwise, because that is their function. Whether the event was recorded is not confirmed. Until it is, the reach of the grant is the only reliable measure of exposure.

The distance between what you said and what the policy allows was the exposure from the first request. It did not open when the request succeeded. It was present the moment the grant was written and the denial was not. The successful request only made the gap observable. The gap closes in the policy or it stays open. Controls that are not enforced are not controls. Identity is the boundary. The policy is the control. What you said was never in the evaluation, and the system will keep deciding as if you never said it.