TL;DR: AI security now depends on how agents are integrated, with hyperscaler builders, orchestration frameworks and custom runtimes each creating different runtime control gaps as systems move from chatbots to agentic AI, according to Straikerai. Static training-time controls are no longer enough when agents can choose tools and execute actions at runtime.
At a glance
What this is: This is an analysis of how AI integration models change the security problem for agentic applications, with runtime visibility and guardrails emerging as the central control need.
Why it matters: IAM and security teams need to treat AI agents as runtime actors whose access paths, telemetry and enforcement points vary by integration model, not as ordinary applications with static boundaries.
Context
Agentic AI changes the control problem because the system is no longer just producing output. Once an AI can choose tools, call APIs and act inside workflows, the security question shifts from model quality to runtime governance across identities, permissions and observable behaviour.
The integration model matters because it determines where policy can actually be enforced. SDKs, proxies, browser extensions, eBPF sensors and gateways each provide different visibility and different limits, so teams need to align controls to the actual execution path rather than assume one control layer fits all.
Key questions
Q: How should security teams implement runtime guardrails for AI agents and MCP traffic in production?
A: Security teams should place guardrails at the gateway or control plane where model, tool, and MCP traffic already converges. That lets them inspect prompts, responses, tool calls, and tool output before action is taken. The goal is to block unsafe execution in real time, not after the fact, while keeping policy centralized and consistent across teams, models, and agent workflows.
Q: Why do agentic AI systems create more security risk than standard chatbots?
A: Agentic systems can turn model output into action, which means a bad instruction can affect code flow, tool use, and downstream state. Standard chatbots usually stop at text generation. Agentic AI adds execution authority, so compromise can lead to disclosure, unauthorized changes, or misuse of credentials.
Q: What are the signs that AI agent observability is failing?
A: The main signs are missing tool metadata, disconnected traces between agent hops, unexplained retries, and an inability to reconcile a successful call with the actual state change it caused. If operators can see that a tool ran but cannot prove what it changed, observability is not yet enough for production control.
Q: What should teams do when first-party and third-party AI agents share the same data flows?
A: Apply different collection and authorization assumptions to each path. First-party systems can use embedded SDK telemetry, while SaaS or browser-based agents usually need proxies or sensors. The key is to avoid assuming one monitoring model covers both trust zones.
Technical breakdown
Why integration model determines the control plane
AI integration model is the architecture choice that decides where an agent sits relative to applications, APIs and data stores. A hyperscaler builder may centralise identity and access integration, while orchestration frameworks and custom agent stacks distribute control across more tools, services and runtime paths. That changes where telemetry can be collected and where policy can be enforced. When an agent can choose actions at runtime, security has to observe the decision path, not just the code or training data that produced it.
Practical implication: Map each AI integration pattern to its enforcement point before production rollout.
Runtime visibility versus training-time assurance
Training-time controls can reduce bad outputs, but they do not govern what an agent does after deployment. Runtime visibility captures model inputs, outputs, tool calls and network activity while the agent is acting, which is where misuse, prompt injection and covert exfiltration appear. This matters most for agentic applications because legitimate APIs can be abused without obvious malicious code. The control gap is not detection in general, but enforcement at the moment the agent decides to act.
Practical implication: Put monitoring and policy decisions at runtime, not only in model development workflows.
SDKs, proxies and eBPF sensors answer different questions
These collection methods are not interchangeable. SDKs provide developer-level telemetry inside first-party systems, proxies inspect higher-level traffic for SaaS and third-party agents, and eBPF or sensor-based capture observes system calls and network activity from cloud or Kubernetes workloads. The architectural point is that each approach sees a different slice of the same agent behaviour. If teams only instrument one layer, they create blind spots that agentic systems can exploit through legitimate interfaces.
Practical implication: Select telemetry based on where the agent executes, then combine methods where the risk surface spans multiple layers.
Threat narrative
Attacker objective: The objective is to manipulate or abuse agentic behaviour at runtime so the system performs unauthorised actions while appearing to operate normally.
- Entry occurs through AI deployment patterns that embed agents into workflows, browsers and back-end systems with different levels of runtime control.
- Escalation happens when orchestration layers or custom agent stacks let the system choose tools and call APIs with insufficient policy enforcement.
- Impact is covert data exposure, tool misuse or instruction smuggling that occurs through legitimate interfaces rather than obvious malware activity.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime control is the real security boundary for agentic AI. Once an agent can choose tools and act inside workflows, training-time filtering stops being the decisive defence. The article’s architecture choices show that the control point moves to where the agent executes, not where the model was trained. Practitioners should design enforcement around the runtime boundary, not around the model lifecycle.
Integration diversity creates governance debt. Hyperscaler builders, orchestration frameworks and custom stacks each expose different telemetry and policy constraints, which means one control pattern will not cover the whole programme. That fragmentation is especially visible in identity governance because the agent’s access path changes by platform and by execution layer. Teams should expect different trust assumptions across the same AI estate and govern them explicitly.
Agentic AI turns observability into an access-control problem. When model traces, tool calls and network requests are the only reliable evidence of agent behaviour, detection and authorization start to converge. This is where the identity of the AI system matters: the system is not just consuming credentials, it is acting with delegated authority. Practitioners should treat runtime telemetry as a control input, not just a monitoring feed.
AI integration sprawl will force a named control concept: runtime guardrail mismatch. The security failure is not simply too little logging or too many tools. It is the mismatch between where teams assume policy lives and where agentic decisions actually occur. That mismatch will keep widening as organisations mix SDKs, proxies, eBPF sensors and gateways. Practitioners should align guardrails to execution path before agent rollout expands further.
Identity governance must expand from human access to delegated machine action. Agentic applications may still authenticate through familiar IAM patterns, but their real risk lies in what they can do after authentication succeeds. That requires security teams to track delegated authority, tool scope and runtime enforcement together. Practitioners should bring agent identity and authorisation into the same governance conversation as human access.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Runtime guardrails will become the decisive control plane for agentic AI. Security teams should expect policy enforcement to move closer to execution because model behaviour alone does not reveal whether an agent is about to misuse a tool or data path. As deployment patterns diversify, the ability to bind policy to the runtime path will matter more than the sophistication of the model stack.
Identity governance now has to follow delegated machine action. Agentic systems are not just users of credentials, they are actors whose access can change by workflow and by integration layer. That means programme owners need to govern the identity of the agent, the scope of its tools and the observability of its actions as one control problem.
Runtime guardrail mismatch: the emerging failure mode is the gap between where teams assume policy exists and where the agent actually makes decisions. That gap widens when organisations mix SDKs, proxies, browser extensions and eBPF sensors without a clear control model. Practitioners should standardise how each execution path is enforced before scaling agentic deployments.
For practitioners
- Map each agent integration path Inventory every model, API, data store and execution layer an agent can touch, then tie each path to the control point that can actually enforce policy.
- Separate first-party from third-party monitoring Use SDK telemetry for developer-owned systems, but switch to proxy, browser or sensor-based collection when the agent runs in SaaS or external contexts.
- Enforce runtime policies on tool use Define approved tool scope, data access and action boundaries at runtime so an agent cannot silently expand beyond its intended role.
- Route traces into detection workflows Send model inputs, outputs, tool calls and network events into a central detection pipeline so anomalous agent behaviour can be investigated quickly.
- Reassess governance when integration changes Treat a move from builder to orchestration framework to custom runtime as a governance change, not just a development choice, because the enforcement model changes with it.
Key takeaways
- AI integration choices now determine where agentic AI can be observed, constrained and investigated at runtime.
- Static controls are weaker than runtime guardrails when agents can select tools and execute actions across workflows.
- Identity and access teams need to govern delegated machine action, not just model deployment or prompt quality.
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 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents acting with delegated access across runtime paths. |
| ASI02 — Tool Misuse | Tool misuse is a core risk in orchestration frameworks and custom agentic architectures. | |
| Recommendation — Bind agent privileges to the runtime path and limit tool scope to what each workflow requires. Monitor and restrict tool invocation so agents cannot call functions outside approved intent. | ||
| NIST AI RMF | MANAGE — AI risk management | The article is about operationalising runtime AI controls across deployment models. |
| Recommendation — Operationalise AI risk controls at deployment time and maintain them as the agent stack changes. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The runtime threats discussed map to misuse of legitimate interfaces and data movement. |
| Recommendation — Map agent misuse scenarios to credential access and exfiltration techniques in threat hunting. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly points to authorisation boundaries for AI agents. |
| Recommendation — Review and limit entitlements for every agent integration path before production use. | ||
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.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
- Integration Model: The architectural pattern that defines how an AI system connects to applications, APIs, telemetry and enforcement points. Different integration models create different visibility and control options, which is why security teams need to match monitoring and policy enforcement to the actual runtime path.
- Delegated Machine Action: Delegated machine action is work performed by an AI agent under authority inherited from a human or system sponsor. The identity remains non-human, but the accountability path still traces back to the original delegate. In practice, this makes runtime behaviour, not just issuance, the governance concern.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for practitioners who need to extend identity controls into agentic systems. It helps security and identity teams connect runtime AI risk to the access models their programmes already own.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org