AI agent vocabulary maps to the production stack teams govern

At a glance

What this is: This article maps AI agent vocabulary to production infrastructure and argues that the real governance unit is the runtime stack, not the model by itself.

Why it matters: IAM, NHI and AI governance teams need a shared way to locate responsibility for prompts, tools, harnesses and delegated agents, because those layers determine control scope and auditability.

Context

AI agents are not governed by model choice alone. Once prompts, tools, memory, stop conditions and delegated sub-agents enter the picture, the security problem shifts from model evaluation to runtime governance and inventory.

This matters because the article treats agent vocabulary as an architectural map, not a naming debate. For teams responsible for IAM, NHI and agentic AI governance, the question is where each control boundary sits in the production stack and who owns it.

Key questions

Q: How should teams govern AI agents when model, prompt and harness are separate layers?

A: Treat the agent as a runtime assembly, not a single model decision. Govern the model, scaffold and harness separately, because each layer changes behavior in a different way and each creates its own review, access and rollback requirement. That approach keeps change control aligned to the actual control boundary instead of the marketing label.

Q: Why is inventorying AI agents harder than counting model deployments?

A: Because a usable inventory has to count registered definitions, runtime loops, tool grants and delegated sub-agents, not just model endpoints. Two systems can share the same model and still behave differently if their prompts, tools or harness logic differ. Inventory must therefore reflect operational behavior, not just components.

Q: What do security teams get wrong about tools, skills and sub-agents?

A: They often collapse all three into a single delegation category, which hides the different governance needs behind each one. Tools need per-call authorization, skills need provenance and versioning, and sub-agents need identity, isolation and traceability. If those controls are not separated, policy gaps appear exactly where the system can act on its own.

Q: What is the difference between agent policy and model versioning?

A: Model versioning tracks one input to behavior, but policy covers the combined effect of the model, scaffold, tools and harness. The same checkpoint can behave very differently when prompts, tool descriptions or loop rules change. Teams should therefore test and approve the full configuration, not assume a model swap tells the whole story.

Technical breakdown

Model, scaffold and harness: where control boundaries actually sit

The model is only the reasoning core: it generates output but does not execute tools, retain durable state or manage control flow. The scaffold is the instruction and context layer the model reads, including prompts, tool descriptions and output formats. The harness is the runtime machinery that invokes the model, interprets tool requests, executes actions, handles errors and decides when to stop. In practice, these layers create different governance surfaces. A prompt edit changes behavior differently from a loop or approval change, even if both are called “agent updates.”

Practical implication: Treat prompt content, execution logic and model weights as separate governed artifacts, not one undifferentiated agent change.

Tool, skill and sub-agent are different delegation models

A tool is a single action, usually a function call. A skill is a packaged procedure that the agent can load and follow for a multi-step task. A sub-agent is a separate reasoning delegate with its own context and runtime. Those distinctions matter because the governance burden changes at each rung. Tool use needs per-call authorization. Skills need provenance and version control. Sub-agents need bounded identity, isolated context and traceability for their own decisions. Flattening them into one category obscures the control gap between execution and delegation.

Practical implication: Map each delegated capability to the right control surface before you decide how it is authorized, reviewed and logged.

Policy lives in the whole runtime, not just the weights

The article treats policy as the behavior the system actually exhibits, which is shaped by the model, scaffold and harness together. That means two deployments with the same model can behave differently if their prompts, tool sets or loop rules differ. In governance terms, the model version is only one input to operational risk. The policy boundary includes everything that changes what the system can do, what it sees and when it stops. That is the same reason inventory based only on model names misses the real control problem.

Practical implication: Version and test the full agent configuration as a policy unit, not just the underlying model checkpoint.

NHI Mgmt Group analysis

Vocabulary standardisation becomes a governance control once it is tied to runtime addresses. A glossary alone does not change security posture, but a glossary that maps model, scaffold, harness, tool and sub-agent to concrete infrastructure makes inventory and accountability possible. That is especially relevant in AI and NHI governance, where control failures often start with ambiguous ownership rather than overt misuse. Practitioners should treat terminology alignment as an enabler for access control, review and audit.

Agent governance is really stack governance. If the model is only one component, then certification, change control and incident response have to follow the whole system that shapes behaviour. This is the same lesson IAM teams already know from privileged workflows: the effective control boundary is where action is taken, not where intent is generated. Practitioners should govern the runtime path, not just the model endpoint.

Delegation creates a new identity problem inside AI systems. Once an agent can invoke tools, load skills or spawn sub-agents, the question is no longer only what it can say but what it is allowed to do on behalf of the enterprise. That makes identity, authorization and traceability first-class design concerns for agentic AI. Practitioners should align delegated action with least privilege, bounded context and auditable execution.

Policy drift will come from configuration change faster than model change. The article is right to frame prompts, tool descriptions and harness logic as behavior-defining inputs. In operational terms, this means the most dangerous drift may sit in versioned artifacts that teams do not traditionally treat as security-relevant. Practitioners should include agent scaffolds and harness settings in change review, evaluation and rollback planning.

Named concept: policy-as-stack. The article’s most useful contribution is the idea that policy is the combined effect of model, scaffold, harness and delegated runtime components. That concept matters because it reframes governance from model-centric oversight to full-stack behavioral control. Practitioners should adopt that lens when defining inventory, approvals and incident boundaries for agentic systems.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Policy-as-stack is the right mental model for agentic governance. Teams that only track model versions will miss the real behavior change, because prompts, tools, memory and delegation rules shape what the system can actually do. The operational question is no longer whether an agent exists, but which runtime components are permitted to change its state and action path. For practitioners, that means change control has to cover the full agent assembly, not just the checkpoint.

Delegation inside AI systems creates a new control boundary around identity and privilege. Once an agent can call tools or spin up sub-agents, authorization is no longer a front-door concern alone. The meaningful boundary is the one that decides which action is permitted, by whom, in which context and with which trace. For IAM and NHI teams, that makes agent runtime design a governance issue, not just an application feature.

For practitioners

• Define the agent as a governed runtime object Inventory each agent by model, scaffold, tools, skills and sub-agents, then assign an owner for each control surface rather than treating the agent as a single application.
• Separate prompt change control from runtime change control Route scaffold edits, harness logic updates and model swaps through different review paths so that a prompt revision is not mistaken for a harmless content tweak.
• Apply least privilege to delegated capabilities Authorize tools per call, version skills as reusable procedures and isolate sub-agents with bounded permissions and traceable execution.
• Make traces part of the audit record Retain governed Agent Harness traces as the evidence trail for who acted, which tools ran and what context the agent used when it made a decision.

Key takeaways

• The article shows that AI agent governance depends on mapping vocabulary to runtime components, not on refining terminology in the abstract.
• Model, scaffold, harness, tools, skills and sub-agents each sit on a different control surface, so they require different governance decisions.
• For practitioners, the main implication is that inventory, approvals and audit evidence must follow the full agent stack if they are to be meaningful.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Scaffold: Scaffold is the instruction layer an AI agent uses to interpret its task, including prompts, output formats, tool descriptions, and carried context. It shapes behaviour by telling the model how to work, but it does not execute anything by itself.
• Subagent: A subagent is a secondary AI worker that performs a narrower task inside its own context and authority boundary. It helps keep the main model clean, reduces confusion from bulk data, and supports more auditable task separation.
• Policy: Policy in an agent system is the effective behaviour produced by the model, scaffold, tools, and harness together. In practice, it is broader than model versioning because changes to prompts, permissions, or runtime logic can alter what the system does.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management through a practitioner lens. It is designed for teams that need to connect identity controls to the systems and runtimes they now govern.