America’s AI Action Plan raises the bar for AI security governance

At a glance

What this is: America’s AI Action Plan reframes AI security around innovation, infrastructure, and security, with runtime access control and transparency at the center.

Why it matters: It matters because IAM, NHI, and AI governance teams will need to align procurement, threat modeling, and runtime controls to a policy environment that expects auditable behavior, not just compliant paperwork.

👉 Read Zenity's analysis of America's AI Action Plan and AI security

Context

America’s AI Action Plan treats AI security as a governance problem, not just a model-risk problem. The article’s central point is that procurement, infrastructure, and policy now have to account for how AI behaves at runtime, what it can access, and how much blast radius it can create.

For IAM and NHI programmes, that means the conversation shifts from static approvals to continuous control over access, tool use, and data exposure. The same pressures now shaping AI policy also expose familiar identity failures: over-permissioned service accounts, weak session boundaries, and limited visibility into third-party access.

Zenity’s analysis uses the policy moment to argue that AI systems must be evaluated as security subjects, not merely software features. That is a familiar lesson for identity teams: when access becomes dynamic, governance has to move closer to execution.

Key questions

Q: How should security teams govern AI systems that can access tools and data at runtime?

A: Treat them as non-human identities with dynamic privileges. Define every reachable resource, restrict the system to task-scoped access, and require logs that prove what it accessed and when. Governance fails when approval happens once but execution continues to expand in real time.

Q: Why do AI systems complicate traditional least-privilege design?

A: Because least privilege is usually set at provisioning time, while AI systems can select actions during execution. That means permission boundaries must follow the session, not just the role. If the system can chain tools or invoke plugins, the blast radius is determined by runtime scope, not initial intent.

Q: What do security teams get wrong about AI and access control?

A: They often treat model approval as if it were the same as access approval. It is not. A safe model can still become a risky identity if it can reach too many tools, too much data, or too many downstream systems. Control must sit at the point of use.

Q: Who is accountable when an AI system misuses delegated access?

A: Accountability sits with the organisation that granted the access and the team that defined the boundaries. The model does not create governance on its own. If the system can act on behalf of users or services, ownership must include identity lifecycle, monitoring, and revocation paths.

Technical breakdown

Runtime access control for AI systems

AI systems create a control problem that sits between identity governance and application security. If a model, agent, or plugin can reach data or tools at runtime, then access is no longer just a provisioning decision. It becomes a live authorization problem involving scope, session boundaries, and output handling. In practice, this is closer to controlling a non-human identity than to reviewing a static application. The relevant question is not whether the system is approved, but whether it can reach the right resource at the right moment and nothing beyond that.

Practical implication: map every AI system to its reachable data, tools, and identities before approving production use.

Blast radius control in AI governance

Blast radius is the operational limit on how far a compromised or misused AI system can move across data, tools, and workflows. In AI settings, the main drivers are over-permissioned agents, weak session isolation, and unvetted plug-ins that expand reach beyond the original task. That is why classic perimeter thinking fails. If the system can call tools, write data, or chain actions, the damage path is determined by runtime privilege, not model sophistication. This makes least privilege and session scoping central design variables, not secondary hardening steps.

Practical implication: constrain AI agents to task-scoped permissions and remove broad standing access from their execution path.

Why open standards matter for AI security

The policy emphasis on openness reflects a practical security issue: opaque systems are harder to test, benchmark, and audit. Open standards improve interoperability, but they also make it easier to assess whether identity, access, and data-handling controls are actually enforced. For security teams, this matters because AI assurance depends on evidence. You need to know what was trained, what can be accessed, and what changed after deployment. In that sense, transparency is not just a policy preference. It is a prerequisite for meaningful governance.

Practical implication: require audit evidence, benchmark results, and access documentation before accepting AI systems into regulated workflows.

Threat narrative

Attacker objective: The attacker or misuser aims to turn a trusted AI workload into a high-reach execution path for data access, action chaining, or exfiltration.

1. Entry occurs when an AI system, plug-in, or agent is connected to sensitive data or tools without sufficiently narrow runtime boundaries.
2. Escalation happens when the system inherits broader access than the task requires, allowing tool calls, data writes, or chained actions beyond intended scope.
3. Impact appears as data exposure, unauthorized workflow execution, or widened blast radius across connected systems and downstream identities.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI policy is now a runtime governance problem, not a procurement checkbox. The article is right to link innovation with security, because the highest-risk failure mode is no longer whether AI is allowed, but what it can do after it is allowed. NIST-style governance only matters when access, telemetry, and enforcement are visible at the moment of use. Practitioners should treat AI approval as the start of control design, not the end.

Blast radius control is the named concept that should replace vague AI trust language. When an AI system can call tools, write data, or chain actions, the risk is defined by how far it can move if something goes wrong. That makes session boundaries, scoped permissions, and data egress rules the real governance primitives. Security leaders should measure AI by reachable impact, not by model size or vendor claims.

Over-permissioned AI behaves like an over-privileged non-human identity. The article’s warning about unvetted plug-ins and runtime misuse maps directly to the NHI problem space: access granted too broadly becomes an execution path for unintended action. OWASP NHI and NIST CSF are relevant here because the failure is not model intelligence, but identity reach. Practitioners should align AI governance with the same controls used for other machine identities.

Open standards matter because opaque AI systems are unauditable AI systems. The policy emphasis on transparency is useful only if organisations can test what the system can access, trace what it did, and prove what changed. That is the same assurance gap seen in machine identity governance, where undocumented privileges create hidden exposure. Practitioners should insist on evidence, not assurances, before placing AI into regulated workflows.

The market is moving toward AI systems that are governed like identity subjects. That shift will pressure builders to document permissions, observability, and runtime controls more carefully, while buyers will need to re-evaluate whether their current identity stack can handle autonomous access patterns. The implication is simple: AI governance is converging with identity governance, and teams that separate the two will miss the real control gap.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For a broader control lens, see Top 10 NHI Issues for the recurring identity failures that still drive exposure.

What this signals

Blast radius control: as AI systems gain more runtime autonomy, the question for practitioners is not whether they are approved, but how far they can move if trust breaks down. That is why session boundaries, reachable resources, and revocation paths now matter as much as model quality.

Identity teams should expect AI governance to merge with machine identity governance rather than sit beside it. The operating model will need stronger evidence of access scope, better auditability, and tighter coordination between IAM, security engineering, and AI platform owners.

The policy direction also reinforces a familiar NHI pattern: once access is dynamic, posture depends on visibility and control at runtime. Organisations that already struggle with third-party OAuth visibility or over-privileged service accounts will feel the same pressure when AI systems start acting as delegated identities.

For practitioners

• Map AI runtime privileges before deployment Inventory every data source, tool, and downstream workflow an AI system can touch, then remove anything not required for a specific task scope.
• Enforce task-scoped session boundaries Treat each AI interaction as a bounded session with explicit start and end conditions, and prevent the session from inheriting broader standing access.
• Require audit evidence for access and behavior Ask for logs, benchmark results, and configuration records that show what the system accessed, what it changed, and how exceptions were handled.
• Align AI governance with identity controls Use existing identity review, privilege management, and monitoring processes to govern AI systems that act on behalf of users or services.

Key takeaways

• America’s AI policy shift makes runtime access control a core governance issue, not a niche security concern.
• The most important risk is blast radius, because AI systems can expand impact through tools, data, and chained actions once access is granted.
• Practitioners should govern AI systems like non-human identities, with task-scoped permissions, evidence-based auditability, and clear revocation paths.

Key terms

• Blast Radius: Blast radius is the amount of damage an identity or system can cause if it is misused or compromised. In AI and NHI governance, it is measured by the data, tools, and workflows the actor can reach, not by how advanced the system appears.
• Runtime Authorization: Runtime authorization is the decision to allow or block an action while a system is actually executing, not just when it is provisioned. For AI systems and other non-human identities, this is essential because access can expand or change during a session.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another or to use shared resources for a defined purpose. It becomes risky when the delegation outlives the task, lacks traceability, or cannot be revoked quickly enough.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: America's AI Action Plan: Innovation, Security, and What It Means for Builders and Buyers. Read the original.