A model-plus-harness configuration is the specific pairing of a base model with the runtime framework that drives it. This pairing matters because the same model can produce different security outcomes when the scaffold, tool routing, or prompt assembly changes.
Expanded Definition
Model-plus-harness configuration refers to the operational pairing of a base model with the runtime layer that shapes how it behaves in production. In agentic systems, the harness can include prompt assembly, tool permissions, routing logic, memory handling, guardrails, and policy enforcement. The model itself is only part of the security posture; the harness often determines whether outputs stay constrained or become action-capable.
Definitions vary across vendors and engineering teams, but the security meaning is consistent: two deployments using the same model can expose very different NHI risks if one harness can call secrets, execute workflows, or escalate privileges. That is why NHI Management Group treats the configuration as a first-class governance object, not a mere implementation detail. For a broader control lens, see the NIST Cybersecurity Framework 2.0 and the NHIMG discussion of Ultimate Guide to NHIs.
The most common misapplication is treating the model as the sole security boundary, which occurs when teams approve a model once and ignore changes to tool routing, prompts, or privilege scope.
Examples and Use Cases
Implementing model-plus-harness configuration rigorously often introduces operational friction, requiring organisations to weigh faster deployment against tighter control over tool use, data access, and logging.
- A customer support agent uses the same model in two environments, but one harness only drafts replies while the other can open tickets and query internal systems.
- A code assistant is wrapped in a harness that can read repositories, but only a separate, approved configuration can access CI/CD secrets or deploy artifacts.
- An internal workflow agent routes invoices through a model that summarizes documents, while the harness decides whether to approve, reject, or escalate based on policy checks.
- A security copilot uses a constrained harness for analysis, but a higher-trust configuration is required before any tool call can rotate credentials or modify IAM state.
- During incident review, teams compare the production harness against the baseline in the Twitter Source Code Breach context and validate expectations against the NIST Cybersecurity Framework 2.0.
These use cases show why the harness must be versioned, reviewed, and tested alongside the model, especially when the agent can reach secrets, service accounts, or privileged APIs.
Why It Matters in NHI Security
Model-plus-harness configuration matters because the harness is often where non-human identity risk becomes executable. A model may be harmless in isolation, but once the surrounding runtime can fetch tokens, trigger actions, or chain tools, the deployment inherits the identity and privilege profile of everything it can touch. That is why the configuration must be assessed with the same discipline used for NHI inventory, access review, and secret governance.
NHI Management Group reports that 97% of NHIs carry excessive privileges, which helps explain why harness scope needs strict control and continuous review. The same research also shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, reinforcing that misuse often emerges through runtime access paths rather than the model weights themselves. See also the NHIMG coverage of Ultimate Guide to NHIs for broader lifecycle context and the NIST Cybersecurity Framework 2.0 for governance alignment.
Organisations typically encounter this risk only after an agent misroutes a tool call, exposes a secret, or performs an unauthorized action, at which point model-plus-harness configuration becomes operationally unavoidable to address.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic guidance centers on tool routing and runtime control, which define this pairing. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Harnesses frequently broker secrets and tokens, linking the term to secret handling risk. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege map directly to model-harness execution scope. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero trust requires explicit authorization for each action the harness can trigger. |
| NIST AI RMF | AI risk management addresses system context, not just model behavior, which includes harness design. |
Limit harness permissions to the minimum required and revalidate them when the configuration changes.
Related resources from NHI Mgmt Group
- How should teams design an agent harness so the model can act safely without constant human configuration?
- What breaks when harness controls are treated like ordinary configuration?
- Why do AI pentesting results improve when a model is wrapped in a harness?
- Why do AI agents need a harness instead of relying on the model alone?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
