AI agent vocabulary maps to the production stack teams govern

At a glance

What this is: This is a mapping of emerging AI agent terminology to the production infrastructure that implements it, showing that the real governance surface sits in the harness, tools, and runtime controls rather than the model alone.

Why it matters: It matters because IAM, PAM, and AI governance teams need to control agent behavior at the points where permissions, execution, and traces exist, not just where the model is named.

👉 Read TruFoundry's mapping of AI agent terms to production infrastructure

Context

AI agent governance breaks down when teams treat vocabulary as architecture. The article’s central point is that words such as model, scaffold, harness, tool, skill, and sub-agent only become meaningful once they are tied to the systems that execute them, and that is where access control, approval gates, and traceability have to live.

That matters for identity and access programmes because an AI agent is not just an LLM call. It is a runtime with credentials, tool reach, and execution boundaries, which means the same governance patterns used for NHI, privileged access, and workflow control now need to extend into agent infrastructure.

Key questions

Q: How should teams govern AI agents without treating the model as the only control point?

A: Governance should follow the full runtime, not just the model checkpoint. Teams need approval gates for tool use, version control for prompts and procedures, isolation for sub-agents, and traceability for every governed run. If the harness changes, policy changes, even when the model does not.

Q: Why do AI agents create more identity risk than traditional LLM applications?

A: AI agents create more identity risk because they can persist state, choose tools, and carry out actions over time. Traditional LLM applications usually produce outputs inside a single request-response cycle, but agents can act across workflows and reuse access. That makes privilege, traceability, and impersonation much harder to govern.

Q: What do security teams get wrong about AI governance inventories?

A: They often inventory only the AI they built themselves and miss embedded AI inside vendor platforms and other shadow AI. That creates a false sense of control because the real decision surface is broader than the visible project list. A useful inventory must cover models, use cases, agents, owners, and the approvals attached to each one.

Q: What should organisations do first when moving from chatbots to agents?

A: Start by defining the runtime boundaries before scaling the use case. Decide which tools are allowed, who approves execution, how context is managed, and what traces are retained. That sequencing matters because the main risk is not the model itself, but the permissions and automation around it.

Technical breakdown

Model versus harness: where AI agent behaviour actually lives

The model is the reasoning component, but it does not execute tools, persist state, or decide when to stop. The harness is the runtime that wraps the model with a loop, tool invocation, error handling, sandboxing, and termination logic. In operational terms, the model is only one input to behaviour, while the harness determines how that behaviour is expressed in production. That distinction matters because two systems using the same model can behave very differently if their harnesses enforce different tools, approvals, or context handling.

Practical implication: Treat harness configuration as a governed runtime artifact, not an implementation detail.

Scaffold, tools, skills, and sub-agents are different governance layers

The scaffold is the instruction layer, including prompts, formats, and tool descriptions. Tools are discrete actions, skills are packaged procedures, and sub-agents are delegated reasoning units with their own context and permissions. These are not interchangeable. A tool call needs authorization, a skill needs provenance and versioning, and a sub-agent needs identity boundaries and isolation. Collapsing all of them into one undifferentiated "agent" category hides the different control surfaces that security and platform teams must manage.

Practical implication: Apply controls by delegation type so permissions, review, and isolation match the action being taken.

Policy is broader than the model version

In agent systems, policy is the effective behaviour produced by the combination of model weights, scaffold content, harness logic, and tool access. That means versioning only the model leaves most of the policy unchanged from a governance perspective. A prompt edit, a tool description change, or a stop-condition change can alter outcomes as materially as a model swap. For AI security teams, policy therefore needs to be treated as a composed runtime state with change control, evaluation, and traceability.

Practical implication: Version and test the full agent stack, not just the underlying model checkpoint.

NHI Mgmt Group analysis

Vocabulary is becoming a governance control plane. The article shows that shared AI agent terminology is not just semantic cleanup. Once model, scaffold, harness, tool, skill, and sub-agent are mapped to concrete infrastructure, governance can finally attach to each layer. That makes inventory, accountability, and control design possible in a way a loose "agent" label never does. The practitioner conclusion is simple: if the team cannot name the runtime component, it cannot govern it.

AI agents create an identity problem as much as a runtime problem. The interesting security question is not only what the model can do, but what identity, permissions, and traces are attached to the agent while it acts. That is where this topic intersects with NHI governance, because agents increasingly behave like non-human identities with tool reach and bounded execution rights. The practitioner conclusion is to treat agent identity, not just model access, as part of the control surface.

Context engineering is the new operational boundary for agent safety. The article makes clear that what the model sees at each step is managed by the harness, not by a static prompt. That means context accumulation, offloading, and compaction become security-relevant because they shape what the agent can infer and act on. The practitioner conclusion is to govern context handling as part of production policy, especially where sensitive data or regulated workflows are involved.

Policy drift is now a stack problem, not a model problem. The post correctly implies that behavioural changes can come from prompts, tools, harness logic, and runtime permissions even when the model stays fixed. That complicates change management because teams can no longer rely on model versioning as the main control point. The practitioner conclusion is to evaluate AI systems the way identity teams evaluate privileged workflows: as a governed chain of decisions and permissions, not a single component.

Registered agent definitions are the foundation for auditability. The article’s strongest operational insight is that once an agent becomes a defined runtime object with named model, tools, and skills, it can be inventoried and traced. That is the difference between an architecture conversation and a vocabulary debate. The practitioner conclusion is to require a canonical agent registry before scaling deployment, approvals, or reporting.

What this signals

AI agent programmes are moving faster than the control structures built to govern them, which is why the distinction between model, harness, and delegated action will matter operationally over the next planning cycle. Teams that can only describe the model will struggle to explain who approved the action, which tool was used, or what trace proves the decision.

Agent runtime sprawl: the real risk is not just more agents, but more loosely governed execution paths with credentials attached. That makes the agent registry, approval workflow, and trace retention model part of the security baseline rather than optional platform hygiene. For identity teams, the next step is to align agent inventory with NHI governance and the control patterns described in the OWASP Agentic AI Top 10.

The practical signal for enterprises is that policy review must shift left into architecture design. If prompts, tools, and harness logic are all policy-bearing artifacts, then change control, evaluation, and traceability need to cover the entire stack before agents are allowed into regulated workflows.

For practitioners

• Govern the agent harness as a runtime control Document the loop, approval gates, sandboxing, error handling, and stop conditions as controlled runtime settings rather than implementation notes. That gives security and platform teams a reviewable control boundary when behaviour changes in production.
• Separate authorization for tools, skills, and sub-agents Treat function calls, reusable procedures, and delegated reasoning as distinct delegation types with different approval, versioning, and isolation requirements. This prevents overbroad access from being granted simply because the system is called an agent.
• Build an agent inventory from registered definitions Create a canonical registry that records model name, scaffold version, tool grants, skills, and sub-agent references for every deployed agent. This makes count, ownership, and audit evidence possible across the AI estate.
• Version policy as a full stack artifact Put prompts, tool descriptions, harness settings, and model references under the same change-control and evaluation process. A prompt edit can be as behaviourally important as a model swap, so treat both as policy changes.

Key takeaways

• AI agent governance fails when teams treat the model as the system, because the harness, tools, and runtime logic determine most of the behaviour.
• Delegated action creates distinct control needs for tools, skills, and sub-agents, so one permission model cannot safely cover all three.
• Agent inventories only become auditable when they are built from registered definitions that capture model, scaffold, tool grants, and traces.

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.
• 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.
• 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.

What's in the full article

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

• Concrete infrastructure mapping for each glossary term, including where models, MCP servers, skills, and traces live in the platform
• Illustrative agent definition examples showing how runtime components are registered and governed
• Expanded discussion of harness engineering, context engineering, and policy versioning across the full agent stack
• Product-specific implementation notes for teams that need to operationalise the vocabulary in production

👉 TruFoundry's full post covers the stack mapping, runtime boundaries, and governance implications in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and the identity controls that now intersect with agentic AI. It helps security and identity practitioners translate runtime behaviour into governance decisions across modern enterprise platforms.