TL;DR: Model Context Protocol context poisoning can redirect an autonomous AI agent from legitimate work to data export, tool misuse, and role drift without triggering traditional API alarms because the calls still look valid, according to Salt. The real governance gap is that security teams often review actions after execution, while agent context can change the action plan before anyone sees it.

NHIMG editorial — based on content published by Salt: LLMs, MCP, and how attackers can hijack AI agents using compromised NHIs

Questions worth separating out

Q: How should security teams govern AI agents that can change actions at runtime?

A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path.

Q: Why do valid API calls not guarantee that an AI agent is behaving safely?

A: Because each call can be individually authorised while the overall sequence is malicious.

Q: What breaks when an AI agent’s role can be rewritten during a session?

A: Static privilege models break because they assume the actor’s purpose is known at provisioning time and remains stable.

Practitioner guidance

• Protect agent context as a governed asset Classify the agent’s goal, tools, role, memory, and constraints as part of the control surface and track changes to those attributes as you would identity privilege changes.
• Baseline normal agent behaviour Record expected tool sequences, data destinations, and role boundaries for each agent so that deviations such as new databases, new export paths, or unfamiliar destinations are detectable.
• Limit the blast radius of each agent Scope each autonomous agent to the minimum viable dataset and tool set, and separate read, transform, and export functions so that a poisoned context cannot immediately exfiltrate records.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• How the article maps agent context into goal, tools, role, memory, and constraints.
• The practical logic behind detecting role drift and behaviour change in autonomous systems.
• The article’s framing of API baselining as a way to connect actions back to intent.
• Salt’s own discussion of discovery, posture governance, and run-time threat protection for AI and MCP environments.

👉 Read Salt's analysis of MCP context poisoning and AI agent risk →

MCP context poisoning for AI agents: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: MCP deployments push OAuth Dynamic Client Registration back into focus because manual client setup does not scale for AI agents and non-technical users, according to Tailscale. The core issue is not registration alone but who is allowed to create clients, because that governance decision defines the real security boundary for MCP access.

NHIMG editorial — based on content published by Tailscale: Easy, Secure Dynamic Client Registration for MCP and AI Agents

Questions worth separating out

Q: How should security teams handle Dynamic Client Registration in remote MCP deployments?

A: Security teams should treat Dynamic Client Registration as a high-risk identity workflow, not a convenience feature.

Q: Why do AI agents make OAuth client registration harder to govern?

A: AI agents can multiply the number of clients, gateways, and delegated access paths that need oversight.

Q: What breaks when MCP gateways sit between users and backend servers?

A: The original user context can disappear unless the delegation chain is preserved explicitly.

Practitioner guidance

• Constrain client registration with identity policy Limit DCR access to specific SSO-backed groups, and require every registration request to map to an approved operator or team.
• Separate direct access from delegated access paths If an MCP server can be reached directly, keep that path simple.
• Add lifecycle controls for OAuth clients and agent gateways Track who created each client, what scope it has, and when it should be revoked.

What's in the full article

Tailscale's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples for using DCR with a locally hosted OAuth authorization server and MCP clients.
• Practical ACL policy examples showing how to restrict registration to approved identities and groups.
• Identity-aware gateway patterns for cases where direct MCP access is not enough.
• Implementation discussion of STS token exchange for intermediary agents and proxies.

👉 Read Tailscale's analysis of secure dynamic client registration for MCP and AI agents →

MCP authorization and dynamic client registration: what changes for teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Cryptographically attached network identity, OIDC/OAuth, and device posture signals let users authenticate with fewer prompts while extending that identity into SaaS and MCP access flows, according to Tailscale. The real governance question is whether existing IAM controls still make sense when identity is continuously asserted at the network layer, not re-checked at each app.

NHIMG editorial — based on content published by Tailscale: Zero trust with zero clicks, a new take on IdPs

Questions worth separating out

Q: How should security teams govern zero-click identity without losing control?

A: Start by separating authentication assurance from downstream authorization.

Q: Why do zero-click login models change IAM risk decisions?

A: They move trust from repeated human prompts to continuous signal propagation.

Q: What breaks when device posture becomes the main access signal?

A: Access decisions can become overdependent on endpoint telemetry that was never meant to replace lifecycle governance or privilege review.

Practitioner guidance

• Define where identity assurance is established Map which systems prove identity at the network layer, which prove it at the application layer, and which consume it only as an input.
• Review device posture as an access policy input Classify posture attributes such as OS version, MDM status, geolocation, and endpoint risk score into mandatory, conditional, or advisory signals.
• Test MCP authorization before production rollout Validate whether your IdP, registration flow, and token service can support MCP-specific authorization patterns without weakening client registration controls or expanding scope unnecessarily.

What's in the full article

Tailscale's full blog post covers the operational detail this post intentionally leaves for the source:

• How tsidp is configured as an OIDC and OAuth authorization server inside a private tailnet.
• How Tailscale device posture and application capabilities grants are combined into access decisions.
• How MCP-specific authorization flows can be supported through Dynamic Client Registration and Security Token Service capabilities.
• How the zero-click model changes the user login path for locally hosted and SaaS applications.

👉 Read Tailscale's blog post on zero-click identity and tsidp for OIDC, OAuth, and MCP access →

Zero-click IdPs and MCP authorization: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: As enterprises connect AI agents to production systems through MCP, governance shifts from model safety to controlling which servers run, who approves them, and what they can do, according to Akto. The real issue is not hallucination but agent compromise through executable tool access and weak runtime guardrails.

NHIMG editorial — based on content published by Akto: What Is MCP Governance? A Guide to Govern MCPs (third-party and internal)

Questions worth separating out

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility.

Q: Why do MCP environments create more identity risk than standard API integrations?

A: MCP environments increase identity risk because they add tool discovery, delegated access, and multiple authentication paths on top of existing APIs.

Q: What breaks when MCP governance stops at approval and ignores runtime behaviour?

A: Approval without runtime control leaves a gap between what was reviewed and what actually executes.

Practitioner guidance

• Define a trusted MCP registry Create a single allowlist of approved MCP servers with name, owner, source, version, and approval status.
• Enforce runtime restrictions on tool-capable servers Limit each MCP server to the smallest practical OAuth scopes, isolate untrusted servers in sandboxes or containers, and log every tool execution with parameters, timestamps, and responses for SIEM review.
• Require re-approval on version or permission change Treat new releases, dependency changes, and expanded permissions as governance events.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• The exact approval workflow for third-party MCP servers, including manifest review and version pinning.
• The implementation details for runtime logging, sandboxing, and scope restriction across server types.
• The suggested lifecycle checkpoints for scanning, staging, production approval, and re-validation.
• The team roles and ownership split used to keep MCP governance accountable over time.

👉 Read Akto's guide to governing third-party and internal MCP servers →

MCP governance for AI agents: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: As organisations move from generative AI to agentic AI, the security problem shifts from prompt safety to governing agents that call tools, assume identities, and act across APIs, according to Akto. The operating model now depends on inventory, risk assessment, guardrails, and response because static IAM assumptions break when software can act independently.

NHIMG editorial — based on content published by Akto: CISO Strategy for Agentic AI Security in 2026

By the numbers:

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

Questions worth separating out

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts.

Q: What breaks when organisations only inventory AI agents without watching their actions?

A: Inventory alone creates a false sense of control because it records existence, not behaviour.

Practitioner guidance

• Build an agentic asset graph Map every AI agent, the identities it assumes, the tools it can invoke, and the data domains it can reach.
• Red-team agent decision paths Test for prompt injection, context poisoning, tool chaining, and unexpected data exposure in workflows that can reach production systems or financial APIs.
• Enforce runtime guardrails on sensitive actions Require human validation for payment approvals, configuration changes, and other state-changing operations, and keep approved tool catalogues narrow.

What's in the full article

Akto's full blog post covers the operational detail this post intentionally leaves for the source:

• The article’s step-by-step framing for building an agent, tool, and identity inventory across a live environment.
• The specific guardrail patterns the vendor recommends for sensitive actions such as payments and configuration changes.
• The vendor’s practical examples of what to monitor, block, and log during agentic incidents.
• The survey prompt and benchmark callout tied to the vendor’s broader AI agent security programme.

👉 Read Akto's CISO strategy for agentic AI security in 2026 →

Agentic AI security in 2026: what CISOs need to prioritise now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Enterprises are converging on a five-layer agentic AI security stack that spans discovery and governance, identity, runtime guardrails, MCP visibility, and continuous red teaming, according to Akto. The core issue is not prompt safety alone but controlling agent behaviour, tool access, and downstream actions before autonomous systems outpace governance.

NHIMG editorial — based on content published by Akto: Founding Team Agentic AI Security, the current market landscape

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

Questions worth separating out

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features.

Q: Why do agentic AI systems need more than prompt-level security controls?

A: Prompt-level controls only inspect content, while agentic systems create risk through tool use, workflow triggering, and downstream execution.

Q: What breaks when organizations do not inventory AI agents and MCP connections?

A: Security teams lose the ability to answer what exists, what it can reach, and who owns it.

Practitioner guidance

• Build a complete agent and MCP inventory Catalog every agent, MCP server, tool, and downstream resource with named ownership, data flow mapping, and review dates so the security team can see the full action surface.
• Classify agent credentials as governed NHIs Assign explicit owners to tokens, secrets, and permissions used by agents, then review them for over-provisioning, shadow deployment, and drift from the approved use case.
• Enforce runtime blocking at the execution path Place controls at the proxy, gateway, endpoint, or network layer so unsafe tool calls, data leakage, and chained actions can be blocked in context before they complete.

What's in the full article

Akto's full post covers the operational detail this post intentionally leaves for the source:

• The full five-layer market map for agentic AI security and how vendors cluster across it.
• The article's detailed view of which control plane owns governance, identity, runtime, MCP proxying, and red teaming.
• The broader market-direction commentary on where enterprise budgets are likely to move in 2026.
• The source's discussion of how security may move directly into agents, MCP servers, and downstream application infrastructure.

👉 Read Akto's analysis of the agentic AI security stack landscape →

Agentic AI security stacks: what is your team missing today?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: At an AWS AI Agents Hackathon, more than 250 developers built 50-plus projects around agentic workflows, with MCP, multi-LLM patterns, and in-browser security checks emerging as the dominant themes, according to Semgrep. The real issue is that faster agent-enabled development is expanding identity, tool, and trust boundaries before most governance models are ready.

NHIMG editorial — based on content published by Semgrep: an analysis of MCP, agentic AI workflows, and secure development patterns

Questions worth separating out

Q: How should security teams design MCP server access for AI agents?

A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints.

Q: Why do AI coding agents create different governance risks from normal developer tools?

A: AI coding agents combine code execution, context persistence, external tool access, and memory across sessions.

Q: What do organisations get wrong about multi-LLM development workflows?

A: They often focus on choosing the best model and ignore where enforcement happens.

Practitioner guidance

• Classify every MCP connection as a trust decision Inventory which agents, IDEs, and browser tools can reach internal services, then require explicit approval for each MCP server and remote tool path before it can access code, secrets, or context.
• Move scanning into the authoring session Run deterministic security checks before generated code leaves the browser or IDE, so unsafe patterns are blocked at the point of creation rather than discovered in later review stages.
• Separate model choice from control enforcement Allow teams to swap LLMs for cost or quality reasons, but keep policy enforcement, secret detection, and code validation independent of whichever model produced the output.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• Project-level examples from the hackathon, including how teams wired security scans into MCP-enabled development flows.
• Specific workflow patterns for browser-based AI coding and the guardrails used to keep generated code under inspection.
• The design choices behind multi-LLM evaluation and how teams compared output quality, speed, and security characteristics.
• The practical shape of pre-flight checks for external MCP servers, including posture review and code scanning steps.

👉 Read Semgrep's analysis of MCP, agentic AI workflows, and secure development patterns →

MCP in developer environments: what it means for security teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: MCP moved from niche spec to enterprise interface layer in a year, with adoption driving privileged tool access, visibility gaps, and a new security category, according to Akto. The real issue is not protocol popularity but the governance assumption that agents can safely inherit human-paced controls.

NHIMG editorial — based on content published by Akto: One Year of MCP: How it Became the Foundation for Enterprise Agentic AI

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.

Questions worth separating out

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role.

Practitioner guidance

• Inventory every MCP server and owner Create a current register of all MCP servers, the systems they reach, the teams that created them, and the identities they depend on.
• Scope every tool to a named business action Replace broad tool permissions with explicit action boundaries that reflect what the tool should do in production, not what it could do in theory.
• Remove hardcoded secrets from MCP configurations Scan server configs, local development environments, and CI pipelines for embedded tokens, then rotate and replace them with managed secrets or workload identity patterns.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Specific examples of MCP server deployment patterns across IDEs, internal platforms, and CI/CD workflows
• The article's own breakdown of how developers and security teams split on governance versus enablement
• Akto's description of its MCP Security category and how it frames discovery, permissions, and oversight
• Additional references to related resources on MCP governance, attack matrices, and AI agent security

👉 Read Akto's analysis of how MCP became the foundation for enterprise agentic AI →

MCP as enterprise plumbing: what it means for agentic AI security?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: As MCP adoption grows, discovery tools are being used to detect servers, map agent-tool relationships, and monitor AI-to-API interactions across cloud, hybrid, and on-prem environments, according to Akto. The governance issue is not visibility alone but whether identity, permissions, and oversight can keep pace with fast-changing agentic connections.

NHIMG editorial — based on content published by Akto: Best MCP Discovery Tools in 2026

Questions worth separating out

Q: How should security teams govern MCP access in agentic workflows?

A: Security teams should govern MCP access as delegated identity, not simple application connectivity.

Q: Why do MCP deployments increase identity and access risk?

A: MCP increases risk because it connects untrusted model output to real systems that can act on it.

Q: What breaks when MCP tools are exposed without policy controls?

A: Without policy controls, MCP tools become a discoverable privilege surface rather than a governed capability set.

Practitioner guidance

• Map every MCP endpoint to an owning identity Build an inventory that ties each MCP server, connector, and API path to an accountable owner, an approved use case, and an expiry review date.
• Review agent-to-tool permissions as one control set Combine agent access review, tool authorization, and permission analysis into a single workflow so teams can see when an agent has broader tool reach than the task requires.
• Enable continuous change tracking for MCP-connected services Alert on new servers, connector changes, permission shifts, and unusual tool invocation patterns.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Specific feature descriptions for automated MCP server and API detection across cloud, hybrid, and on-prem environments
• The vendor's comparison of static, dynamic, agent-centric, and network-based discovery approaches
• Tool-by-tool positioning across Akto, Kong, Lasso Security, Prompt observability platforms, and MCP-Manager
• Detailed claims about prompt injection, tool poisoning, insecure auth, and data leak testing inside discovered MCP endpoints

👉 Read Akto's guide to the best MCP discovery tools in 2026 →

MCP discovery tools: what IAM and security teams need to see?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: AI agents are increasingly making decisions and triggering workflows through APIs and MCP, creating a security gap where visibility, governance, and detection lag behind usage, according to Salt. The core issue is assumption collapse: access reviews and static privilege models were built for stable identities, not runtime actors that can change behaviour mid-session.

NHIMG editorial — based on content published by Salt: AI agents, MCP, and the expanding API attack surface

Questions worth separating out

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.

Q: Why do AI agents complicate least-privilege access models?

A: Because agents often use shared or long-lived NHIs, move quickly, and cross platform boundaries that human-centric review processes do not cover well.

Q: What breaks when AI agent access is inherited directly from the user who triggered the workflow?

A: Direct inheritance collapses two different subjects into one security decision.

Practitioner guidance

• Inventory every agent-facing API path Map which AI agents, MCP servers, and downstream services are connected, then classify each path by data sensitivity, action capability, and ownership.
• Separate read access from action authority Do not let an agent that needs context also inherit write or transaction privileges by default.
• Log runtime context, not just API calls Capture the agent identity, prompt or task context, tool invoked, target system, and outcome.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• The article spells out Salt's view of how AI agents, LLMs, and MCP connect to production APIs in practice.
• It outlines the visibility, governance, context, and detection capabilities the vendor says are required for secure deployment.
• It describes the security problem from the vendor's API-centric perspective, including how it interprets agent misuse and downstream exposure.
• It provides the vendor's own framing for why AI agent traffic will expand and how that changes the attack surface.

👉 Read Salt's analysis of AI agent API risk and MCP exposure →

AI agent identity risk and MCP access: are controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →