Harness Engineering: Why Your AI Agents Need Guardrails Before They Need Autonomy
Most organizations have built their AI coding strategy around picking a model and pointing it at their codebase. What they haven’t built is the infrastructure around the model: the tools it can reach, the identity it acts under, the approval gates it must pass, and the record it leaves behind. That surrounding apparatus is called a harness, and harness engineering is the discipline of designing it deliberately.
This reframes the buying decision as model quality converges. The harness is what you build once, govern centrally, and can’t easily replace. Treating it as an afterthought is like standardizing on a database vendor before thinking about access control.
How can an AI harness be attacked?
Security researcher Simon Willison coined the phrase “the lethal trifecta” to describe when agent deployments become genuinely dangerous. Three conditions, all present at once: the agent has access to sensitive systems, it’s exposed to untrusted content (issue descriptions, code comments, third-party tool output), and it can act without human approval. All three together mean an attacker who can write a comment in a public repository can issue commands to an agent operating inside your infrastructure.
GitLab documents this threat model explicitly, including worked attack sequences. In one, an attacker embeds hidden instructions in a public merge request. A developer runs a review agent on it. The agent reads the injection, executes a command to read the developer’s private SSH key, and posts that key as a review comment. Nothing malfunctioned. The model followed instructions it found in its context. The problem was in the harness.
What good governance looks like
GitLab’s Duo Agent Platform reached general availability in GitLab 18.8, and the governance layer it shipped with is a useful map of what to look for in any agent platform.
Bounded identity means every agent action is tied to two identities: a service account and the human who triggered it. The agent’s effective permissions are the intersection of the two, always resolving to whichever is more restrictive. Privilege escalation is structurally unavailable rather than policed after the fact.
Duo’s tool governance classifies every agent tool as read, write, or delete, then lets you set each to always allow, always ask, or always deny. Writes and deletes require inline human approval by default. Rules cascade from group to project, and a project can only make a rule stricter, never looser. If the governance service errors out, the agent gets no tools at all rather than defaulting to permissive.
Architecture also functions as a control. Instead of one generalist agent with both read and write access, split it into two: a reader that analyzes and produces a summary, and a writer with exactly one tool that posts it. The writer never sees the original content. Injected instructions can corrupt the analysis but can’t reach anything that writes.
The bottom line
The constraint on agent adoption is the security review that won’t approve an agent nobody can bound, and the audit that can’t distinguish human work from machine work. Those are harness problems. They get solved by design, in advance, or expensively after an incident.
If you want help thinking through agent governance for your GitLab environment, reach out to us.