Many engineers assume that a service account automatically secures every machine‑to‑machine call, but the token alone does not enforce any guardrails. In reality, a GCP service account can be copied, its key can be embedded in scripts, and any process that presents the token can reach the target without oversight. This misconception leaves teams exposed to credential leakage, uncontrolled command execution, and no visibility into what automated agents actually do. The missing piece is an effective **non-human identity** enforcement strategy that goes beyond simple authentication.
Typical deployments of MCP (Model‑Control‑Plane) servers on GCP rely on a single non‑human identity – a service account created in the project and granted the minimal IAM role required to invoke the server’s API. Engineers embed the JSON key in CI pipelines, store it in secret managers, or mount it into containers. The connection then proceeds directly from the container to the MCP endpoint. While the identity is “non‑human,” the path offers no runtime checks: there is no session recording, no inline data masking, and no just‑in‑time approval step. If an attacker compromises the container, the service account can be abused indefinitely, and the organization has no audit trail to prove what commands were run.
That baseline – a non‑human identity that authenticates but does not enforce – is the starting state we must improve.
Non‑human identity and the need for a data‑path gateway
Non‑human identity solves the “who” problem: it tells the MCP server which principal is making the request. It does not solve the “what” or “when” problems. Without a control point that inspects each request, the following gaps remain:
- Unrestricted command execution: any script with the key can issue privileged operations.
- No real‑time data protection: responses that contain secrets travel in clear text to the caller.
- Zero auditability: security teams cannot reconstruct a timeline of automated activity.
- Missing approval workflow: high‑risk actions fire without human review.
These gaps exist even though the service account is a non‑human identity. The enforcement point must sit between the identity provider and the MCP server.
Architectural requirement: a data‑path enforcement point
To turn a non‑human identity into a secure, governed access channel, the system must introduce a gateway that intercepts every protocol exchange. The gateway must be the only place where policy can be applied, because the service account itself cannot be trusted to enforce limits. This data‑path component performs three essential duties:
- It validates the OIDC token presented by the service account and maps group membership to fine‑grained permissions.
- It records each session, enabling replay and forensic analysis.
- It applies inline masking, just‑in‑time approval, and command blocking before the request reaches the MCP server.
By placing these controls in the data path, the organization gains visibility and restraint without changing the existing service account or the MCP server configuration.