What is the difference between the agent chassis and the AI model?

The model generates suggestions, while the chassis executes, mediates and constrains those suggestions in a deterministic runtime. That difference matters because identity, secrets, logging and outbound requests are governed where actions happen, not where text is produced. Security teams should design around execution, not generation.

What the chassis does that the model cannot

The model is the reasoning and generation layer. It produces candidate text, plans, or tool suggestions, but it does not itself own the runtime that applies policy, identity, logging, or outbound controls. The chassis is the execution layer that decides what can happen, records what did happen, and constrains the model’s outputs before they become real actions.

That separation is more than architecture jargon. A model can recommend a dangerous action with no authority to perform it, while the chassis can refuse, rewrite, require approval, or scope the action to a specific task. For agentic systems, the security boundary sits where the action is executed, not where the suggestion is generated.

Why the distinction matters for security design

When teams treat the model as the security boundary, they often misplace controls in the wrong layer. Identity, secrets, network access, approvals, and auditability need to be enforced by the chassis because that is where requests become tool calls, API calls, file writes, or other side effects. A safer model is still useful, but it is not a substitute for runtime control.

This is also why the chassis must mediate prompts, memory, tool access, and request context. If a suggestion can trigger outbound traffic, retrieve secrets, or invoke privileged workflows, the chassis needs to apply policy at decision time. For practical guidance on those boundaries, see AI Agent Authorisation Guide and Agentic AI Identity Guide.

The same distinction explains why observability belongs in the chassis. The model can emit tokens, but the chassis can attribute actions, correlate requests, and retain evidence of what was executed. That makes incident review and containment possible when an agent behaves unexpectedly. The control point for those records is the runtime, not the model weights.

How to think about agent failure modes

A model failure is usually a quality problem: hallucination, bad reasoning, or unsafe suggestions. A chassis failure is a control problem: overbroad permissions, missing approvals, weak logging, unsafe tool exposure, or unrestricted egress. Both matter, but only the second one turns model output into a real-world security event.

That means the hardest failures are usually composed failures. The model makes a poor suggestion, and the chassis lets it pass because the guardrails are thin, the permissions are too broad, or the action is not checked against policy. In a mature design, the model may still be wrong, but the chassis prevents that error from becoming a high-impact action. For a deeper threat view, Agentic AI Security Guide and AI Agent Observability, Audit and Incident Response Guide are useful next reads.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent suggestions become risky when chassis permissions are too broad.
	ASI02 — Tool Misuse	The chassis governs whether model output can invoke tools or side effects.
	ASI09 — Human-Agent Trust Exploitation	The chassis must prevent overtrust in model output becoming unsafe execution.
Recommendation — Enforce per-action authorization to prevent privilege abuse in the chassis. Restrict tool invocation to approved actions and scoped contexts. Require human approval for high-impact actions and escalation paths.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Chassis-controlled actions depend on secure handling of secrets and tokens.
	AU-2 — Audit Events	Runtime actions need logs at the chassis, not just model text output.
Recommendation — Rotate and protect credentials used by the execution layer. Log authoritative execution events where the action is performed.

Practitioner Guidance

What to prioritise: Draw the trust boundary around execution, not generation. If the chassis can call tools, reach data, or move money, treat it as the security control plane and assess it like any other privileged runtime.

What to verify: Confirm that each action path has a policy decision point, a policy enforcement point, and a log record that ties the action back to the request that triggered it. If you cannot reconstruct the chain, you do not have a defensible control.

Common mistake: Teams harden the model prompt or fine-tune for safer language, then assume the system is safe. That can reduce bad suggestions, but it does not stop an over-scoped chassis from executing them.

Practitioner takeaway: The model is a source of intent, the chassis is the source of authority. Security quality depends on making sure the authority layer is deterministic, least-privileged, and observable.