Security teams should move the control point closer to the workload, at the agent harness or framework layer, where tool calls, file writes, and API actions actually occur. A bastion host can still support segmentation, but it cannot reliably govern machine-speed decisions already inside the environment. Practical control requires identity, authorisation, and audit at the moment of action.
Why This Matters for Security Teams
A bastion host can still help with segmentation, but it is the wrong primary control plane for autonomous workloads. Agentic systems do not behave like human admins using predictable jump-box sessions; they chain tools, call APIs, and make machine-speed decisions that happen well after the user-facing boundary has been crossed. That is why security teams need identity, authorisation, and audit at the point of action, not just at the network edge.
The risk is visible in current research. NHIMG’s The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, while 85% lack full visibility into third-party OAuth apps. For agentic workloads, that confidence gap matters because the workload itself can become the attacker path. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime governance, not static trust zones.
In practice, many security teams discover the control gap only after an agent has already issued an unsafe tool call or accessed data it was never intended to touch.
How It Works in Practice
The practical alternative is to move enforcement into the agent harness, orchestration layer, or tool gateway where each action is requested and approved. That means a policy decision can evaluate the agent’s identity, the tool it wants to use, the data it wants to reach, the current task context, and the risk of the request before execution. This is closer to intent-based authorisation than classic perimeter control.
For most environments, the control stack should include workload identity, short-lived credentials, and policy-as-code. Workload identity gives a cryptographic root of trust for what the agent is, not just what secret it has. The SPIFFE workload identity specification is a useful model here because it supports short-lived, verifiable identity for services and agents. JIT issuance of credentials reduces blast radius when the agent only needs access for a single task. Static, long-lived secrets are especially poor fit for autonomous systems because the agent may invoke tools in ways no human operator anticipated.
Operationally, teams should:
- authenticate the agent with workload identity before any tool call
- issue ephemeral tokens with narrow scope and short TTLs
- evaluate every request against policy at runtime, not only at login
- log the tool, target resource, decision, and task context for audit
- revoke or quarantine the workload when behavior drifts from expected intent
This is where NHIMG research on AI Agents: The New Attack Surface report is especially relevant: 80% of organisations report agent actions beyond intended scope, and only 52% can fully track and audit what agents access. These numbers fit the architecture problem. These controls tend to break down when agents operate across many SaaS tools and APIs because policy enforcement is fragmented and the original request context is lost between hops.
Common Variations and Edge Cases
Tighter runtime control often increases integration overhead, requiring organisations to balance stronger containment against developer velocity and operational complexity. That tradeoff is real, especially when agents span multiple clouds, internal APIs, and third-party services.
There is no universal standard for agent control planes yet, so current guidance suggests layering controls rather than searching for a single replacement for the bastion host. Some environments will still use a bastion for administrative access, but the bastion should be treated as one segment in the path, not the decision point for every action. In high-trust internal systems, teams may start with coarse approvals and move toward finer-grained runtime policy as usage matures. In regulated environments, the audit trail matters as much as the block decision itself.
Special cases deserve explicit treatment. Human-in-the-loop approvals may be appropriate for destructive actions, but they do not scale to routine API calls. If an agent has access to secrets, those secrets should be rotated frequently and bound to a specific workload identity, not shared across services. For multi-agent workflows, best practice is evolving toward per-agent identities and per-tool entitlements so one compromised agent cannot automatically inherit the permissions of another. NHIMG’s OWASP Agentic Applications Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reinforce that agent governance must follow the action, not just the session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 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 Agentic AI Top 10 | A1 | Agentic apps need runtime controls at each tool call, not bastion-only trust. |
| CSA MAESTRO | T1 | MAESTRO models agent threat paths that bypass traditional network choke points. |
| NIST AI RMF | AI RMF emphasizes governable, traceable AI behavior across the lifecycle. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived, rotated NHI secrets reduce blast radius for autonomous workloads. |
| NIST Zero Trust (SP 800-207) | PR.AC-5 | Zero Trust requires continuous verification instead of implicit bastion trust. |
Authenticate and authorise each agent request using continuous, contextual policy.
Related resources from NHI Mgmt Group
- How should security teams deploy phishing-resistant passkeys in regulated environments without relying on a cloud identity provider?
- How should security teams authenticate workloads without relying on user MFA patterns?
- How should security teams reduce human approval for agentic AI without losing control?
- How should security teams govern agentic AI access without relying on static RBAC?
