TL;DR: Changing only the harness around the same model can create up to a 6x performance gap, showing that context management and orchestration matter more than raw model capability for security operations, according to Crogl. The real security issue is not model access but whether the surrounding control plane can preserve investigative context, avoid repetition, and keep decisions grounded in the right evidence.
At a glance
What this is: This blog argues that AI security operations depend on the harness around the model, and that scaffold design can change outcomes by as much as 6x on the same benchmark.
Why it matters: For IAM and security teams, the lesson is that AI-assisted operations create a governance problem around context, evidence handling, and task-scoped control, not just model selection.
👉 Read Crogl's analysis of why AI harness design matters in security operations
Context
AI harness design is the control layer that decides what a model sees, retains, and retrieves during a task. In security operations, that matters because the quality of the surrounding orchestration determines whether the system preserves investigative context or turns into an expensive autocomplete loop.
The primary governance gap is not model intelligence but context discipline. When a system can call tools, sift logs, and reason over incident data, it begins to resemble an operational actor that still needs bounded access, traceable decisions, and scoped memory. That intersection makes this topic relevant to NHI and agentic AI governance as well as SOC automation.
The article’s starting position is increasingly typical for teams experimenting with AI in operations: the model is easy to obtain, but the production scaffolding is where the hard work lives.
Key questions
Q: What is the biggest risk in letting AI systems drive security investigations?
A: The biggest risk is not model error alone, but uncontrolled context handling. If the system cannot remember what it already analysed, filter noisy tool output, or preserve entity relationships, it will miss patterns and repeat work. That turns incident response into a confidence problem, where the output sounds coherent but is operationally unreliable.
Q: Why do AI-enabled security tools need governance beyond traditional security controls?
A: AI-enabled tools introduce non-deterministic behaviour, which means security controls must address both the system and the model lifecycle. Traditional controls can show a vendor protects data and infrastructure, but they do not prove the AI’s behaviour is reviewed, monitored, and corrected over time. Governance matters because the risk can change as prompts, models, and features evolve.
Q: How do security teams know if agentic AI controls are failing?
A: The main signs are session drift, repeated retry loops, unauthorized tool calls, and behaviour that diverges from the documented task sequence. If the agent keeps moving through steps after intent-to-tool alignment weakens, the system is drifting beyond its control envelope. In practice, teams should measure the full execution path, not isolated prompts.
Q: How should organisations decide between building and buying an AI harness?
A: Teams should compare lifecycle burden, not just initial feature fit. A real harness must evolve with new attack patterns, new log sources, and changing model behaviour, so the question is whether the organisation can support continuous orchestration tuning. If not, the build becomes a long-term product commitment rather than a weekend project.
Technical breakdown
What the harness controls in an AI SOC workflow
A harness is the orchestration layer around a model. It decides what data to retrieve, what to pass into context, what to retain in memory, and when to call external tools such as a SIEM or case management system. In security workflows, that means the harness shapes evidence selection, entity tracking, and step-by-step reasoning. If the harness is weak, the model can still sound confident while missing prior findings or overloading itself with irrelevant log output. The result is not just lower accuracy, but unstable operational behaviour that looks like analysis and behaves like noise.
Practical implication: treat the harness as a governed control layer, not a prompt wrapper.
Why context management changes detection quality
Context management is the process of deciding which facts remain available as an investigation progresses. In an SOC setting, the system must track hosts, users, alerts, and prior hypotheses without repeatedly reprocessing the same material. The article’s core point is that token limits are not the only constraint. Too much context can degrade reasoning, while too little causes the system to forget crucial relationships. Effective context management therefore works like a working memory discipline, using a knowledge graph or structured state to preserve only what still matters.
Practical implication: define state retention rules before you let AI drive incident analysis.
Why model capability is not the same as operational reliability
The same underlying LLM can perform very differently depending on how the environment constrains it. That is because benchmark success depends on the full system, not just the model weights. The article points to a practical gap between demo-ready orchestration and production-grade reliability, especially when the task spans multiple tools, long investigations, and changing attack paths. In governance terms, this is the difference between a useful assistant and an operational dependency that needs controls for memory, escalation, and evidence integrity.
Practical implication: validate the end-to-end workflow, not the model alone.
NHI Mgmt Group analysis
Harness governance is now a security control, not a developer convenience. Once AI systems can retrieve data, call tools, and shape investigation paths, the surrounding orchestration becomes part of the control stack. That shifts attention away from model capability and toward state handling, evidence selection, and bounded action. In practice, SOC teams need to assess harness logic with the same seriousness they apply to privileged automation.
Context sprawl is the new failure mode in AI-assisted security operations. The article shows that too much context is not automatically better, because unresolved state, duplicate log pulls, and oversized retrieval results can distort reasoning. This creates a named governance problem: context leakage through over-retrieval. Practitioners should treat memory, retrieval, and summarisation as policy decisions, not implementation details.
AI operations will inherit the same trust problems that already shape NHI governance. If a harness can retrieve sensitive telemetry, route tool calls, and act repeatedly within an investigation, it behaves like a non-human operational identity with task-scoped privileges. That makes access boundaries, observability, and revocation relevant even when the system is not a classical service account. The field should expect more convergence between agentic AI security and NHI controls.
Production reliability will separate real AI systems from impressive demos. The article’s central claim is that benchmark lifts emerge from orchestration discipline, not from prompt cleverness alone. That means procurement, architecture, and risk review all need to ask whether the system can hold state, avoid repetition, and adapt as attack patterns evolve. Teams that cannot answer those questions are not ready for operational dependence.
The market is moving toward specialist control planes for AI-enabled security work. General-purpose models will keep improving, but operational value will keep accruing to systems that encode investigation logic, state discipline, and evidence handling. Practitioners should evaluate whether they are buying a model, a workflow, or a governed control layer, because those are not interchangeable choices.
What this signals
Context discipline is becoming an operational security requirement. As AI systems move from summarising incidents to driving investigation steps, teams need policy over retrieval, memory, and tool invocation. The practical signal is that orchestration reviews should join the same control conversation as access review, audit logging, and privilege scoping.
The next phase of AI-in-SOC adoption will reward programmes that can prove state integrity. If the harness cannot show what it knew, when it knew it, and why it chose a specific tool path, the workflow is too fragile for production dependency. That is the same governance instinct that underpins NIST SP 800-53 Rev 5 Security and Privacy Controls in other automation contexts.
Non-human operational actors are starting to look like governed identities. When AI systems can repeatedly access telemetry, maintain task context, and act across multiple tools, the security programme needs a clear model for scope, revocation, and oversight. That makes agentic control design a close neighbour of NHI governance, not a separate concern.
For practitioners
- Define harness governance boundaries Document what data the AI harness may retrieve, retain, summarise, and forward to tools such as the SIEM or case platform. Make the scope explicit for each investigation type so the system cannot expand beyond task-bound access.
- Separate retrieval from reasoning state Store investigation state in structured form, such as entity relationships and prior findings, instead of relying on raw transcript history. That reduces duplicate analysis and limits the chance that irrelevant output consumes the context window.
- Test against long-form incident workflows Validate the harness on multi-host, multi-source investigations that force repeated tool use, not on short synthetic demos. Measure whether it preserves prior conclusions, resists log flooding, and keeps evidence ordering stable.
- Apply least-privilege access to AI tooling Limit each tool call to the minimum permissions needed for the current step, and revoke access paths that the harness does not need for the present case. This matters when the system behaves like a non-human operational actor.
Key takeaways
- AI harness quality determines whether the same model becomes a useful SOC assistant or a noisy liability.
- The critical failure mode is context management, where retrieval, memory, and tool use drift away from the investigation goal.
- Teams should govern AI orchestration as a control layer, because production reliability depends on state, scope, and auditability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Harness access and retrieval decisions map to least-privilege control of operational workflows. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is directly relevant when AI systems can call tools and access incident data. |
| MITRE ATT&CK | TA0007 , Discovery; TA0009 , Collection | The article centres on investigation discovery and collection logic inside AI-driven SOC workflows. |
| NIST AI RMF | MANAGE | AI governance and operational controls are the core issue in harness design and reliability. |
Use MANAGE to define monitoring, escalation, and operational boundaries for AI-assisted security workflows.
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.
- Context Management: The practice of carrying state, memory, and relevant instructions between agents during a workflow. It keeps tasks coherent, but it also creates a persistence layer for sensitive information, so teams must decide what context can move, what must expire, and what should never be shared.
- Knowledge Graph: A knowledge graph is a data model that stores entities and the relationships between them instead of treating records as isolated rows. In security, it helps teams explain how identities, permissions, tokens, and resources connect, which is essential for understanding access paths and risk propagation across SaaS and NHI environments.
- Operational Reliability: Operational reliability is the ability of an AI system to perform consistently under real workload conditions, not just in a demo. It depends on state handling, tool discipline, and bounded decision-making, especially when the system is expected to support investigations or other high-stakes workflows.
What's in the full article
Crogl's full blog covers the operational detail this post intentionally leaves for the source:
- How the harness logic maps investigation state into knowledge-graph updates and retrieval decisions
- Why context limits change once tool calls start returning large result sets from a SIEM or case platform
- Where the article distinguishes demo-ready orchestration from production-grade investigation reliability
- How the author frames the build-versus-buy trade-off for AI-driven security operations
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is a practical fit for practitioners who need to govern automation, access, and lifecycle controls across modern security programmes.
Published by the NHIMG editorial team on September 3, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org