By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: StraikeraiPublished March 19, 2026

TL;DR: RSAC 2026 sessions point to a shift from prompt injection and data leakage toward agentic AI risks such as workflow compromise, tool misuse, privilege abuse, and multi-step attack chains, according to Straiker. The core problem is that conventional model security assumes static behaviour, while agentic systems act across tools, data, and workflows in ways IAM and runtime controls must now govern.


At a glance

What this is: This is a practitioner take on RSAC 2026 that argues agentic AI, not basic prompt safety, is now the main security challenge.

Why it matters: It matters because IAM, PAM, NHI, and security architecture teams need to govern what agents can reach, do, and persist across before tool integrations become the new attack surface.

By the numbers:

  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Straiker's RSAC 2026 agentic AI security session recommendations


Context

RSAC 2026 reflects a broader security governance shift: the problem is no longer just whether a model produces unsafe output, but whether an agent can take unsafe action. In agentic AI, the control question moves from content moderation to runtime authority, tool reach, and workflow impact. That makes AI security inseparable from identity governance, because every meaningful action depends on who or what the agent is allowed to be.

The article argues that most teams are still applying last year’s mental model to this year’s attack surface. That is a common maturity gap, not an edge case. Once AI systems can browse, retrieve, execute, and persist across sessions, the operational boundary becomes closer to NHI governance than to traditional model testing.


Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do AI agents create a different risk model than chatbots?

A: AI agents can act, not just generate. Once they can browse, retrieve, call tools, and complete tasks, the main risk shifts from unsafe output to unsafe action. That expands the attack surface from prompts to workflows, credentials, and downstream systems, which is why traditional model-only controls are no longer enough.

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.


Technical breakdown

Why agentic AI breaks traditional vulnerability scoring

Traditional scoring systems such as CVSS assume a relatively stable vulnerability, a bounded target, and a direct exploit path. Agentic AI changes all three assumptions. The risk is often behavioral, not just technical: a system may be safe in isolation but dangerous when its tools, context, and permissions are combined. That is why agent autonomy, actionability, and multi-step attack chains matter more than a single severity score. Security teams need to understand what the agent can do after compromise, not only whether compromise is possible.

Practical implication: score agent risk by reachable actions and workflow impact, not by model behaviour alone.

AI desktop apps and coding agents as a new endpoint attack surface

Local copilots and AI desktop apps sit at the intersection of model inference, local files, operating system permissions, and developer workflow. When prompt injection, context poisoning, or malicious retrieval reaches a tool-enabled agent, the attack can cross from text manipulation into file access, command execution, or persistence. This is structurally different from browser-only or cloud-only AI risk because the agent is operating with local trust and often elevated developer access. The security problem is no longer only input validation. It is containment of what the agent can touch once the input is accepted.

Practical implication: treat AI desktop tooling like privileged endpoint software and constrain local access tightly.

MCP and tool integrations are turning identity into the control plane

Model Context Protocol connects AI agents to tools and data sources, which makes it useful and risky at the same time. Once an agent can authenticate to an MCP server, SaaS API, or cloud control plane, the security question becomes one of delegated authority, token scope, and session trust. If those credentials are broad, persistent, or poorly monitored, the agent can become a high-speed path from access to action. This is where NHI governance becomes directly relevant: agent identity, token lifecycle, and tool entitlements now define the blast radius.

Practical implication: inventory MCP-connected identities and reduce standing token scope before enabling broader agent workflows.


Threat narrative

Attacker objective: The attacker aims to turn a trusted AI workflow into an execution path for credential theft, unauthorized access, and downstream account or tenant compromise.

  1. Entry occurs when an attacker reaches an AI-enabled workflow through prompt injection, vulnerable desktop tooling, or an exposed tool integration such as MCP.
  2. Escalation follows when the agent executes with local files, API tokens, or SaaS permissions that were granted for productivity rather than tightly scoped tasks.
  3. Impact emerges when the manipulated agent performs unauthorized actions, exposes credentials, or drives downstream compromise across connected systems.

NHI Mgmt Group analysis

Agentic AI is becoming an identity governance problem, not just a model safety problem. The article is right to move the discussion from prompt content to what agents can actually do. Once an AI system can browse, call tools, and persist across sessions, governance has to account for authority, scope, and lifecycle. That is where NHI governance and PAM patterns overlap with AI security. Practitioner conclusion: teams should govern agent permissions the same way they govern other high-risk machine identities.

Workflow compromise is the right named concept for this risk category. The article surfaces a shift from single-event exploitation to multi-step manipulation of task flow, tools, and outcomes. That is materially different from classic endpoint or application compromise because the target is the action chain itself. In practice, the control objective is to restrict which workflows an agent can influence and how far a compromised session can propagate. Practitioner conclusion: limit agent reach to the minimum workflow boundary that still delivers business value.

MCP expands the blast radius of AI systems by turning credentials into control paths. When an agent can authenticate to tools and data sources, token scope becomes the security boundary. If that boundary is broad or persistent, the agent inherits access that may outlive the task. For IAM and NHI teams, this is the same class of problem as over-privileged service accounts, only with faster execution and less human visibility. Practitioner conclusion: reduce standing access before treating MCP as a routine integration layer.

Runtime visibility is now the differentiator between AI governance and AI theatre. The article correctly points out that point-in-time testing cannot catch every attack chain once agents are interacting with live systems. Runtime monitoring, entitlement review, and auditability need to extend to agent actions, not just prompts. That aligns with broader security governance principles in NIST-CSF and zero trust architecture. Practitioner conclusion: if you cannot trace what an agent did, you do not yet control it.

Agent sprawl will outpace policy unless ownership is assigned now. The article’s warning about teams lacking an inventory of agents, tools, and runtime behaviour is becoming the dominant failure mode. In identity terms, this is the difference between having an AI feature and having a governable AI principal. Without ownership, every new agent becomes a shadow identity with unclear accountability. Practitioner conclusion: establish named owners, entitlement baselines, and review cadence before deployment scales further.

What this signals

Workflow compromise is becoming the dominant operational signal for AI governance. Teams should stop asking only whether a model is safe and start asking whether an agent can complete an unsafe chain of actions under real permissions. That requires runtime telemetry, access scoping, and reviewable ownership across the agent lifecycle. Where AI systems touch tools and data, the programme now needs identity-grade controls, not just prompt filters.

AI governance will increasingly converge with NHI controls. As soon as an agent can authenticate to MCP servers, APIs, or SaaS platforms, its tokens and entitlements become machine identities that must be inventoried and reviewed. That is the same governance problem identity teams already face with service accounts, only faster and harder to observe. Aligning with the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 will help close that gap.

Agent sprawl will pressure programmes to move from policy intent to enforcement. If organisations cannot inventory agents, tools, and access paths, they cannot prove control over what the system can do. The practical response is to make agent ownership, entitlements, and runtime logs part of the same governance workflow used for privileged access and sensitive accounts. That is where the identity programme will feel the impact first.


For practitioners

  • Define agent identity ownership Assign a human owner, a business purpose, and an explicit entitlement set to every agent before it is allowed to interact with tools, data, or workflows. This creates a minimum accountability layer for audit and review, especially where agent behaviour crosses into NHI territory.
  • Constrain MCP and tool scopes Map every MCP connection, SaaS token, and API credential used by AI systems, then reduce each one to the narrowest task-scoped permission set possible. Stand up separate credentials for read, write, and administrative actions so one agent cannot inherit broad control.
  • Monitor agent behaviour at runtime Collect logs that show what the agent accessed, which tools it called, what data it retrieved, and which action it completed. Tie those events into SIEM or SOAR workflows so anomalous delegation chains can be detected before they complete.
  • Test for workflow compromise, not just prompt injection Build red-team scenarios that chain prompt manipulation into file access, API calls, or privileged workflow changes. This tests the full attack path the article describes and exposes where runtime guardrails fail once the agent has legitimate access.
  • Separate development and production agent privileges Use different identities, different tokens, and different approval paths for testing agents versus production agents. That reduces the chance that a compromised test workflow can pivot into sensitive systems or long-lived business data.

Key takeaways

  • Agentic AI changes the security problem from unsafe content to unsafe action, which places identity governance at the centre of the control model.
  • The evidence is already clear: 80% of organisations report agent behaviour outside intended scope, and most still cannot fully audit agent data access.
  • Practitioners should respond by assigning agent ownership, narrowing tool scope, and enforcing runtime monitoring before deployments expand further.

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 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A.2The article centres on agentic AI risks, tool abuse, and workflow compromise.
NIST AI RMFGOVERNThe post emphasises ownership, accountability, and AI governance for agent actions.
NIST CSF 2.0PR.AC-4Agent tool access and permissions require least-privilege access control.
NIST Zero Trust (SP 800-207)Agent runtime trust should be continuously verified across tools and sessions.
NIST SP 800-53 Rev 5AC-6Least privilege directly addresses overbroad agent permissions and token scope.

Review agent entitlements against least-privilege expectations and remove unnecessary standing access.


Key terms

  • Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
  • Workflow compromise: A failure mode where the attacker does not need to break the underlying system directly, but instead uses a trusted process to trigger unauthorised action. In email, the workflow itself becomes the attack surface when message content can influence automated decisions.
  • Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
  • Agent ownership: The assignment of accountable business and technical responsibility for an AI agent or automated workflow. Ownership should include approval authority, review cadence, and a clear connection to the identity that the agent uses, so that access and liability do not disappear when the workflow scales.

What's in the full article

Straiker's full blog covers the session-level detail this post intentionally leaves for the source:

  • Speaker-by-speaker RSAC session breakdowns, including the specific talks the author expects to shape the agentic AI agenda
  • Practical examples of how prompt injection, tool misuse, and MCP risk chain into real attack paths
  • The author's reasoning for why AI desktop apps, coding agents, and autonomous workflows are now the primary attack surface
  • A day-by-day list of sessions and the operational themes each one is intended to surface

👉 Straiker's full post breaks down the session list, attack-chain themes, and runtime control gaps in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to control high-risk access. It helps identity and security teams apply consistent governance to the systems and privileges that now underpin agentic AI risk.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org