Independent research and operating notes on AI agent governance.
Gait Series / Post 2 of 4 / Security Leadership
".eslintrc for Agents" Is the Wrong Mental Model
The shorthand lands in executive meetings because it feels familiar: rules in code, reviewed in PRs, versioned over time. It breaks the moment that familiarity gets mistaken for equivalent control strength. Lint can warn or fail checks. Boundary enforcement can prevent side effects from executing. Those are different categories and should be budgeted and reported differently.
In this piece
Implementation context
Gait bootstraps repo policy with gait init and
validates it with gait check, but the repo's core claim
is stronger than a config analogy: structured intent is evaluated at
runtime and non-allow outcomes are non-executable.
Why the analogy survives the first meeting
Leaders need fast translation when a new control category appears. The ".eslintrc" analogy helps because it signals explicit policy, version control, and reviewable changes in normal engineering workflows.
Those instincts are worth preserving. Most organizations do need one legible place to express agent behavior expectations. YAML policy is easier to govern than rules spread across prompts, docs, and exception threads.
Where the analogy fails under pressure
Linting evaluates code artifacts. Boundary controls evaluate action intent at execution time. The first can improve consistency. The second can stop side effects. Once an agent can trigger real changes, this distinction is no longer semantic.
This gap affects funding decisions. Executives hear "lint" and infer a low-friction quality layer. They hear "runtime boundary" and infer a preventive control with operational consequences.
AI governance for write-capable workflows requires the second, plus explicit operating processes for approvals and exceptions.
A concrete comparison clarifies it. A lint-like policy check can flag "do not call production write tool X." A runtime gate can prevent the same call from executing when it reaches the boundary. One influences behavior. The other enforces it.
The better pattern
A stronger model has three coupled layers: policy expression, runtime enforcement, and durable proof. Policy files define intent. Runtime verdicts control execution. Artifacts prove what happened. Missing any layer weakens the overall system.
Gait is useful implementation context because the repo links those layers directly: declarative YAML policy, boundary evaluation before side effects, and trace artifacts suitable for CI and audit reuse. The core lesson is architectural, not brand-specific.
This also improves sequencing decisions. Teams can start with policy expression and validation quickly, then add boundary enforcement on high-consequence paths, then harden proof quality. That phased approach avoids both overbuilding and false confidence.
Why security leadership should care
Security leadership should care because analogy drift creates control drift. If teams overindex on lint framing, they may ship polished policy files without funding execution gates, reasoned verdicts, or durable evidence. The result looks mature in governance decks and weak in incident response.
The CISO does not need perfect terminology, but does need control-class precision. Keep the analogy for onboarding. Specify procurement and reporting in terms of preventive enforcement plus evidence quality.
Why engineering leadership should care
Engineering leadership benefits from the analogy when it lowers adoption friction. But stopping at configuration creates technical debt. The payoff comes when policy joins a reusable control plane with stable verdict semantics, clear failure modes, and CI-usable artifacts.
That is the line between a helpful repo convention and a platform capability other teams can trust under pressure.
What to do next
- Keep the analogy as an introduction, then explicitly classify your controls by execution impact.
- Document where policy transitions from static file to runtime verdict in your current stack.
- Demonstrate one non-allow non-execute example for a high-risk action path.
- Attach decision artifacts to normal engineering review surfaces, not isolated dashboards.
- Evaluate program maturity using incident replay questions, not only repo policy coverage.
The next pressure point is practical and immediate: MCP trust. Static config review helps, but invocation-time boundary decisions are where trust becomes real.