Could this PR expose another team’s secrets?

Example

A pull request extends a shared access policy to compute clusters. Check whether the rendered roles and bindings would grant access beyond each team’s namespace.

1. Read the proposed permissions and resolve the affected cluster and namespaces.
2. Compare the proposed bindings with the observed roles, subjects and workloads.
3. Report the permission at risk, the supporting evidence and a narrower scope to consider.

If the policy grants cluster-wide secret access, flag the cross-namespace risk. If the rendered policy or affected cluster is unavailable, say what could not be verified.

What you need

Your coding agent needs the diff and relevant Helm or RBAC files. Anyshift needs access to the affected Kubernetes environment. Reuse existing connections; a PR URL alone does not give your agent access to a private repository.

• Proposed permissions: Give your agent the diff and rendered Helm or RBAC manifests. It needs repository access separately from Anyshift.
• Live roles and bindings: The Kubernetes integration captures Roles, RoleBindings, ClusterRoles and ClusterRoleBindings, alongside workloads and namespaces.
• Read access: Graph MCP retrieves evidence for your coding agent. It does not apply the proposed policy or submit a GitHub review.

This is an evidence-based review, not a simulation of an unapplied policy. Existing bindings, the rendered manifest and collection timestamps matter. Missing evidence cannot establish that a change is safe.

Review this diff: [paste diff or accessible PR URL]. Use Anyshift Graph MCP to check the impact on [cluster / namespace]. Call describe_schema and confirm the intended project with list_projects before reading resources. Resolve exact resource IDs, then inspect the relevant RBAC relationships. Report any added access to secrets or workloads outside the intended namespace, cite the evidence and name missing context. Do not apply changes or publish a review.