Proxy or bastion based controls can create a narrow choke point, but they do not fully cover the many ways identities reach cloud services, APIs, and data stores. They also tend to miss lifecycle governance, policy consistency, and broad visibility across human and machine access. That leaves gaps in least privilege, auditability, and operational scale.
Why This Matters for Security Teams
Proxy and bastion controls can be useful inspection points, but they are not a complete governance model for cloud access. Cloud identities reach services through SDKs, CI/CD jobs, workload tokens, service accounts, and direct API calls, not just interactive sessions. That means a bastion can sit in the path and still miss the real entitlement problem: who or what can act, for how long, and under what context. Current guidance from the OWASP Non-Human Identity Top 10 treats this as an identity and lifecycle issue, not a network-routing issue.
NHIMG research shows the gap is operational, not theoretical. In the 2024 Non-Human Identity Security Report, only 19.6% of security professionals said they were strongly confident in securely managing non-human workload identities, while 88.5% said their NHI practices lagged behind or merely matched human IAM. In practice, many security teams discover that a proxy did not prevent misuse of an over-privileged token after data movement, lateral access, or API abuse has already occurred, rather than through intentional access design.
How It Works in Practice
A bastion answers one question: can a session be funneled through a controlled hop? It does not answer the harder cloud questions: should this workload have access, what exactly should it reach, and should that privilege exist right now? For that, organisations need workload identity, short-lived credentials, and runtime policy evaluation. The control plane must decide at request time, not simply forward traffic.
That shift is why modern guidance prefers identity-centric controls such as policy-as-code, JIT credential issuance, and cryptographic workload identity. The NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev. 5 Security and Privacy Controls both support least privilege, access review, and continuous monitoring, but cloud implementation has to translate that into actionable workload governance. In practical terms, teams should:
- Bind each workload or agent to a distinct identity rather than sharing a bastion account.
- Issue ephemeral secrets with short TTLs and revoke them automatically when the task ends.
- Evaluate policy at request time using context such as service, environment, data sensitivity, and task intent.
- Log both the requesting identity and the downstream resource touched, not just the proxy hop.
NHIMG’s Lifecycle Processes for Managing NHIs and Top 10 NHI Issues both reinforce that identity issuance, rotation, and deprovisioning are part of the control surface, not after-the-fact hygiene. These controls tend to break down in distributed cloud estates with direct-to-service APIs, CI/CD automation, and cross-account roles because the bastion only sees a fraction of the trust relationships involved.
Common Variations and Edge Cases
Tighter proxy and bastion enforcement often increases operational friction, requiring organisations to balance visibility against automation speed and developer throughput. That tradeoff is real, especially in hybrid cloud environments where humans, workloads, and agents all touch the same services through different paths. There is no universal standard for this yet, but current guidance suggests treating bastions as one inspection layer, not the primary authorisation boundary.
Edge cases appear when access is highly ephemeral, bursty, or machine-to-machine. A CI pipeline may need to assume a role for minutes, an AI agent may chain tools across multiple services, and a data platform job may never traverse a bastion at all. In those cases, static network chokepoints do not express intent well enough. The stronger pattern is to combine identity, context, and lifecycle controls, then reserve bastions for exceptional human administration and regulated break-glass paths. NHIMG’s Regulatory and Audit Perspectives is useful here because auditors will usually ask whether access was justified, time-bound, and reviewable, not only whether it passed through a gateway.
Where organisations over-rely on proxy-based design, the model breaks most visibly in multi-cloud, direct API, and autonomous workload environments, because the real access path bypasses the bastion long before the audit team notices.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Bastion-only models miss workload identity and lifecycle issues central to NHI control. |
| OWASP Agentic AI Top 10 | A-03 | Autonomous agents can bypass proxy assumptions through tool chaining and dynamic access. |
| CSA MAESTRO | IAM | MAESTRO addresses machine and agent access patterns beyond a single network choke point. |
| NIST AI RMF | AI RMF stresses governance and operational monitoring for autonomous decision systems. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust rejects implicit trust in network location or bastion placement. |
Inventory every non-human identity and enforce direct governance over issuance, rotation, and revocation.
Related resources from NHI Mgmt Group
- What breaks when organisations try to govern all identities with the same access model?
- What breaks when organisations try to govern AI with existing privacy or records processes alone?
- Why do organisations struggle to govern dynamic authorisation without a central access view?
- Why do cloud password platforms still create concern for organisations with strict access governance?
