Notifications
Clear all
Topic starter
24/06/2026 10:44 pm
TL;DR: Verifiable deployments from GitHub, Microsoft, Google, CrowdStrike, PagerDuty and Amazon show agentic AI is already in production, but only where access is tightly scoped, actions are review-gated, and identity is task-bound according to Aembit. The hard lesson is that autonomy becomes manageable only when the programme is built around ephemeral privilege, traceability, and explicit boundaries.
NHIMG editorial — based on content published by Aembit: agentic AI deployments and the identity controls that make them safe to scale
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern agentic AI without stopping automation?
A: Security teams should govern agentic AI by separating low-risk recommendation from high-risk execution.
Q: Why do agentic AI systems need workload identity instead of shared API keys?
A: Shared keys make it impossible to tell which agent did what and they enlarge the blast radius if one context is compromised.
Q: What breaks when an agent can choose and execute actions without approval gates?
A: The boundary between analysis and effect disappears.
Practitioner guidance
- Define per-agent workload identities Give every agent its own identity and permissions tied to a single workflow or task.
- Gate high-impact actions behind approval Separate suggestion from execution for merges, endpoint isolation, configuration changes, refunds, and any action that can change production state.
- Sandbox and attest the runtime environment Run agents in restricted environments with limited internet reach, visible logs, and environment checks before any access to control systems.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Workflow-specific examples of how GitHub, Microsoft, Google, CrowdStrike, PagerDuty, and Amazon constrain agent authority in production.
- The practical control combinations used in real deployments, including sandboxing, approval gates, environment checks, and task-scoped credentials.
- Operational guidance on where low-risk autonomy ends and human review should begin for code changes, incident actions, and infrastructure changes.
- Implementation detail on how per-task identities and ephemeral credentials reduce blast radius in live agent workflows.
👉 Read Aembit's analysis of how production agentic AI stays within identity boundaries →
Agentic AI identity controls: what actually makes production safe?
Explore further
25/06/2026 7:31 am
Agentic AI does not fail because it is intelligent. It fails when identity and authority are misaligned with runtime decision-making. The deployments in this article work because access is narrow, temporary, and observable. That means the security problem is not model output quality alone, but whether the identity layer can keep pace with an actor that decides and acts inside the same session. Practitioners should treat the agent as a governed executor, not a smarter script.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, while 37% point to inadequate monitoring and logging.
A question worth separating out:
Q: Who is accountable when an autonomous agent causes a production incident?
A: Accountability sits with the organisation that defined the agent’s authority, controls, and review path. If the agent could act without clear limits, the failure is usually governance design, not just model behaviour. Teams should map ownership across IAM, PAM, security operations, and the business system that authorised the agent.
👉 Read our full editorial: Agentic AI is scaling safely only where identity controls hold
