A newly hired contractor leaves the company, but the service account they used to push logs into a central store remains active. An automated CI job continues to call an internal payment API with a hard‑coded token that never expires. When a breach is discovered, the incident team can see the damage but cannot prove which request originated the malicious call because no audit trail exists.
This is a classic A2A (application‑to‑application) scenario where privileged access management, or pam, is missing. The systems exchange secrets directly, rely on static credentials, and give every caller unrestricted power. The result is an uncontrolled blast radius and no evidence for compliance audits.
Why pam matters for A2A
pam ensures that non‑human identities receive only the permissions they need, for the time they need them. It forces every service call to be tied to an identity that can be audited, revoked, and re‑issued without changing the underlying code. Without pam, a single leaked token can let an attacker traverse multiple services, exfiltrate data, or corrupt production workloads.
Current practice leaves A2A vulnerable
Most teams provision a service account once, embed its secret in configuration files, and grant it broad database, queue, and API rights. The account never rotates, and the secret is copied into every repository that needs it. When developers clone the repo, the credential spreads to personal machines, CI runners, and backup archives. No gate stands between the caller and the target, so there is no place to inspect a request, enforce a policy, or record the interaction.
Because the connection goes straight from the client process to the backend service, the organization cannot enforce just‑in‑time approval, inline data masking, or command‑level blocking. The setup satisfies the authentication requirement – the service knows who is calling – but it provides no enforcement on the data path.
What a proper control surface looks like
The first step is to replace static secrets with short‑lived identities issued by an identity provider. OIDC or SAML tokens give each service a unique subject and group membership. Those tokens are then presented to a gateway that sits on the network edge. The gateway validates the token, checks the caller’s groups, and decides whether the request may proceed.
Even with the right token, the request still reaches the target directly unless a gateway intercepts the traffic. The gateway is the only place where the organization can apply pam controls such as: