Agentic AI security depends on controlling the full harness, not just the model

At a glance

What this is: This explainer breaks agentic AI into its core layers and shows that the security risk sits in the surrounding harness, not the model alone.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern model access, tool permissions, and session-level controls for AI systems that can act, not just respond.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Tailscale's explainer on agentic AI and the full agent stack

Context

Agentic AI is the point at which a model stops being a passive generator and starts participating in an execution loop. The primary governance gap is that many teams still talk about the model as the risk, when the more important control boundary is the surrounding harness: tools, memory, permissions, runtime, and gateway access. That shift matters because once an AI system can inspect, decide, and act, identity governance becomes a real operational concern rather than a theoretical one.

Tailscale’s explainer is useful because it separates the agent stack into layers that security teams can actually reason about. That separation maps cleanly to IAM and NHI governance, where the key questions are not only what the model can say, but what the system can reach, which credentials it can use, and how much authority persists between sessions. For identity-led programmes, this is the same governance problem that appears whenever a non-human identity gains standing access across systems.

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 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 do security teams get wrong about AI agent identity governance?

A: They often assume human IAM patterns can be reused with minor adjustments. That fails because agents can invoke tools dynamically, operate continuously, and combine multiple systems in one session. Governance has to focus on runtime scope, delegated identity, and revocation, not just authentication.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Technical breakdown

What makes an agent different from a chat model?

A chat model produces a response to a prompt and stops. An agent wraps that model in a control loop that can take an action, observe the result, and continue until it reaches a goal. That loop usually includes tools, memory, execution context, and permission checks. The distinction matters because the model itself is not the whole attack surface. Once the system can call APIs, read files, or send messages, the relevant security question becomes whether each step is constrained by policy, scope, and revocation. In identity terms, the agent behaves more like a non-human workload with delegated authority than a simple chatbot.

Practical implication: define agent identity, tool scope, and session boundaries before allowing any production access.

Why the harness is the real security boundary

The harness is the machinery around the model that builds prompts, manages shell or file access, stores memory, and coordinates tool calls. It is also where most governance failures appear, because a model cannot enforce policy by itself. If the harness grants broad context or persistent credentials, the agent can accumulate authority across steps and across sessions. That creates a classic over-privilege problem with a modern interface. Security teams should treat the harness as an identity enforcement layer, not a convenience wrapper, because it determines what the system can actually do in the environment.

Practical implication: enforce least privilege in the harness, not only in downstream applications and APIs.

How model gateways change identity and access control

A model gateway centralises API key management, routing, usage tracking, and access control between agents and model providers. That does not remove risk, but it does create a place where policy, audit, and offboarding can happen consistently. For NHI governance, this is important because model access often fragments across config files, developer laptops, and ad hoc integrations. A gateway turns scattered credentials into a manageable control point. The underlying architecture is similar to other workload identity patterns: centralise trust decisions, narrow the blast radius, and make every model call attributable to a controlled identity.

Practical implication: require a central gateway for provider access so model use can be audited, revoked, and segmented.

Threat narrative

Attacker objective: The objective is to hijack agentic workflows so a trusted AI system can be used to access data, execute actions, or expose credentials beyond intended scope.

1. Entry begins when an agent receives access to tools, data sources, or messaging surfaces through broad permissions or exposed credentials.
2. Escalation occurs when the harness allows the agent to reuse context, memory, or API access beyond the original task boundary.
3. Impact follows when the agent can take actions, query sensitive systems, or move through delegated access without sufficient human review.

NHI Mgmt Group analysis

The core governance problem is agent authority sprawl, not model intelligence. Once an LLM is embedded in a loop with tools, memory, and permissions, the security question becomes how much authority the system can accumulate across steps. That is an IAM and PAM issue as much as an AI issue, because persistent access is what turns a useful assistant into a risky actor. Practitioners should treat agent authority as a lifecycle problem, with issuance, scope, review, and revocation all explicitly controlled.

Agentic AI creates a named governance gap: the harness trust gap. Security teams often review the model, but the harness is where execution policy, sandboxing, and tool mediation actually happen. If the harness is weak, the model inherits more reach than the organisation intended, especially when memory or chained tool calls bridge sessions. That makes policy enforcement at the runtime layer a first-class control objective, not an implementation detail.

Centralised model gateways are becoming the identity control plane for AI systems. The more teams use multiple models and channels, the more scattered their API keys, usage logs, and approval paths become. A gateway does not solve the problem on its own, but it creates the control point where access can be attributed, segmented, and removed. For practitioners, this signals that AI governance is converging with workload identity governance rather than staying separate from it.

Persistent memory changes the meaning of access review. In traditional access governance, reviewers can inspect who has access at a point in time. Agent memory means previous decisions, preferences, and context can persist even when people assume a session is over. That creates a durable non-human identity footprint that must be governed like any other privileged workload. The practical conclusion is straightforward: if memory can influence action later, it belongs in scope for review now.

OWASP-style agent security thinking belongs in NHI programmes, not on the side. Agentic systems combine tool misuse, permission abuse, context leakage, and supply-chain style dependencies into one operating model. That is why identity teams should not treat agent governance as an isolated AI conversation. The same controls used for machine identity, secrets handling, and privileged workflow segmentation are now directly relevant to AI systems that can act on behalf of users.

What this signals

Agentic AI is becoming a governance problem faster than most identity programmes are adapting. The operational signal is clear: agent use is scaling into environments that still lack defined ownership for tool scope, memory retention, and revocation. Teams that already govern machine identities and privileged workflows are best placed to extend those controls here, because the underlying problem is delegated authority, not conversational UX.

Harness-level controls will matter more than model choice. As agents spread across messaging surfaces, terminals, and business workflows, the practical risk is that permissions fragment while auditability weakens. A secure gateway, consistent sandboxing, and explicit offboarding are becoming baseline requirements for any programme that wants to keep AI behaviour inside policy boundaries.

For practitioners

• Define each agent as a governed non-human identity Assign ownership, approved purpose, and access scope to every production agent so its permissions can be reviewed like any other privileged workload identity. Include expiry, offboarding, and exception handling in the identity record.
• Constrain tool access at the harness layer Restrict file, shell, messaging, and API tools to the minimum set required for the task, and enforce sandboxing so the agent cannot step outside the approved execution boundary.
• Centralise provider access through a model gateway Route model calls through one control point for key management, audit logging, and policy enforcement, so provider access can be revoked without hunting through local configuration files.
• Review memory as persistent authority Classify stored context, memories, and reusable skills as governed data with retention limits, review requirements, and deletion rules, because they can carry forward access-relevant decisions across sessions.

Key takeaways

• Agentic AI changes the security boundary from prompt handling to execution governance.
• The strongest control point is the harness and gateway, where permissions, memory, and tools are actually enforced.
• Identity teams should govern agents like privileged non-human identities with clear ownership and revocation paths.

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.
• Harness: The harness is the layer of instructions, policies, and approval logic wrapped around an AI agent. It is where organisations try to constrain behaviour, but it only works if the rules are explicit, current, and enforced outside the model itself.
• Model Gateway: A central routing and control point for model access, API keys, logging, and usage policy. For security teams, it reduces credential sprawl and creates a practical place to enforce audit, segmentation, and offboarding for AI systems that call external models.
• Sandbox: A sandbox is a controlled execution environment that isolates an agent's runtime from the rest of the estate while still allowing defined actions and tool use. For identity teams, the sandbox is part of the trust boundary because it carries the agent's access, state, and audit trail.

What's in the full article

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

• A layered walkthrough of how OpenClaw, Pi.dev, and Hermes differ in gateway, harness, and runtime design.
• Concrete examples of Home Assistant, Telegram, and MCP integration patterns used in a live agent setup.
• Vendor-specific implementation detail on model access routing, memory handling, and sandbox choices.
• The author's hands-on observations on using agentic workflows in a real home automation environment.

👉 The full Tailscale post shows how gateways, harnesses, and runtimes fit together in practice

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It is designed for practitioners who need to connect identity controls to emerging AI and workload risk.