Enterprise AI Compliance: Steerings Over Skills

Engineering teams frequently misconfigure AI coding agents (Copilot, Kiro, Claude, Codex, and others) by relying exclusively on on-demand skills — callable procedures and tool descriptions defined in an agent's tool registry (such as those conforming to the agentskills.io standard) — to enforce strict project rules. This approach fundamentally misunderstands the architecture of foundation models. When compliance mandates are embedded within dynamic tool descriptions, they are subject to conditional execution and instructional distraction. To prevent agents from silently violating security baselines and tooling mandates, organisations must implement a dual-layer architecture: static steerings for immutable boundaries and dynamic skills for isolated execution.

1. The Compliance Illusion

Engineers often assume that writing a rule like "always use yarn, never npm" into an agent's skill ensures obedience. This is false.

Skills operate on an action-triggered basis within the ReAct (Reasoning and Acting) loop. If the agent hallucinates a native solution, misjudges the necessary action, or simply bypasses the tool, the rules for that skill are entirely ignored. This vulnerability is not vendor-specific; it applies universally to all ReAct-based agents, coding or otherwise.

Failure scenario.

A senior engineer asks an AI coding agent to scaffold a new Node.js microservice. The team's skill library includes a scaffold-node-service skill with an explicit constraint: "always use yarn as the package manager." The agent begins reasoning: it recognises that scaffolding requires installing dependencies and, instead of invoking the skill, inlines a sequence of shell commands using npm install — a pattern seen in millions of training examples. No skill is called. The yarn constraint is never read. The resulting lockfile commits package-lock.json to the repository, silently violating the team's tooling mandate. The agent did not malfunction; it simply hallucinated a path that bypassed the governed skill entirely.

2. The Architecture of Forgetting

Relying on skills for governance fails at the foundation model level for three distinct architectural reasons:

• Role Weighting. Foundation models are fine-tuned via RLHF to prioritise the system message role (steerings) over other inputs (Ouyang et al., 2022; Touvron et al., 2023). Tool descriptions are treated as conditional metadata to help the model decide whether an action is needed, rather than as absolute constraints.

• Position Bias. The "Lost in the Middle" study (Liu et al., 2023) demonstrates that LLMs have high recall for information at the absolute beginning of a prompt — where steerings natively reside — and severe degradation for data in the middle. Skills are injected dynamically into this high-degradation middle zone.

• Instructional Distraction. As dynamic data, such as code snippets and tool outputs, fill the context window, the model experiences "instructional distraction" (Wallace et al., 2025). Rules embedded in dynamic payloads fade out, causing agents to silently drop constraints deep into a multi-turn refactoring loop.

3. Steerings and Skills in Practice

Enterprise architecture requires decoupling state (rules) from action (execution). The diagram below illustrates the dual-layer model.

STEERINGS govern ▶ routes actions through SKILLS

STEERING LAYER: State, Always-on, System Prompt	SKILL LAYER: Action, On-demand, Tool Registry
- Always use yarn as a package manager	- scaffold-node-service
- No raw git commands — use allowed tools only	- run-db-migration
- Only use verified Node.js packages	- execute-ci-diagnostics
- Never expose secrets in logs	- safe-package-update
- All outbound HTTP must route through the approved proxy

The Steering Layer (State)

Define your immutable boundaries here. Steerings must remain lean — typically 5 to 10 absolute rules (e.g., "Always use yarn as a package manager", "No raw git commands — use allowed tools instead", "Only use verified Node.js packages listed in the source"). Bloating this layer triggers the same context degradation it aims to prevent.

The Skill Layer (Action)

Maintain an extensive library of skills for specific, repeatable procedures. Use this for tasks such as scaffolding a new Node service, running migrations, or running CI diagnostics.

The Interaction

The lean steering layer acts as an always-on governor. Because the baseline rules are enforced globally — persisting at high attention weight throughout every turn of the session, prior to any tool injection — the agent is architecturally constrained to route its actions through your sanctioned skills rather than attempting to bypass them or execute unsafe native commands. A steering that reads "always use yarn, never npm" is present at position zero of every prompt; a skill-embedded equivalent exists only if and when that skill is invoked.

4. Governing the ReAct Loop

Skills are for playbooks; steerings are for boundaries.

Attempting to govern an enterprise codebase using only tool-level constraints guarantees compliance drift. In strict environments, security and tooling mandates must operate above the agent's conditional logic. The next frontier is auditability: organisations should instrument their agent pipelines to log which layer (steering or skill) intercepted a given action, enabling compliance teams to surface drift before it reaches production.

References

1. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172.
2. Ouyang, L., Wu, J., Jiang, X., et al. (2022). Training language models to follow instructions with human feedback. NeurIPS 2022. arXiv:2203.02155.
3. Touvron, H., Lavril, T., Izacard, G., et al. (2023). LLaMA: Open and Efficient Foundation Language Models. arXiv:2302.13971.
4. Wallace, E., et al. (2025). Instruction Distraction in Long-Context Language Models. (preprint).