Agent Skill Governance for Conflict and Security Boundaries

Security-oriented skill governance is mostly about one thing: refusing to let a convenient instruction become a dangerous one just because it was written naturally. A bloated skill file can hide boundary leaks very well. The same paragraph may define a task, relax a constraint, and explain away the risk. Once that happens, the model has to infer where policy ends and implementation begins, and that is exactly where security mistakes start to slip through.

A public Chinese case described an anomaly-detection agent whose skill file grew from roughly four hundred lines to roughly fifteen hundred lines after automatic repairs. The details matter less here than the pattern: duplicated rules, hidden conflicts, and too many exceptions inside the main surface. In a security setting, those problems are more than style issues. They can become authorization leaks, unsafe overreach, or accidental disclosure paths.

This guide treats the skill as a boundary artifact. Its job is not only to instruct the agent, but also to define what the agent must not assume, must not bypass, and must hand back to a human. That means approvals, versioning, rollback, and reference integrity are not optional extras. They are the security perimeter.

1. Start with trust boundaries, not with writing style

The first question in a secure skill is not “how do we say this clearly” but “who is allowed to decide this”. If the boundary is not explicit, the model may treat a local instruction as if it were a global permission. That is how harmless-looking wording turns into overreach. A rule that says “help the user complete the task” is too broad unless it is boxed in by scope and by refusal behavior.

Trust boundaries should be written in plain terms. State which actions are allowed, which require approval, which are forbidden, and which must be escalated. When a boundary is missing, the model may fill the gap with the most generous interpretation. In normal productivity work that can be annoying; in security-sensitive work, it can be dangerous.

The simpler the boundary language, the easier it is to audit later. Clear scope is not a convenience. It is evidence.

2. Separate policy, execution, and exception handling

Many security failures happen because one paragraph tries to do too much. It defines the policy, gives the operational steps, and then casually mentions exceptions in the same breath. That makes it hard to know which sentence has the highest authority. For security, that is a bad trade. Policy should be one layer, execution another, exceptions a third.

Policy says what the system may never do. Execution says how the allowed task should proceed. Exceptions say when a human must step in. Once these are separated, you can evaluate them independently. If the exception handling drifts, you do not need to rewrite the policy. If the execution changes, you do not need to reopen the security model. Separation keeps the blast radius small.

This also makes automated repair safer. The tool can be told that policy text is high privilege and should not be rewritten casually, while execution details can be refactored more often.

3. Hidden conflicts are a security problem, not a writing problem

A hidden conflict is not just two sentences disagreeing. In a security context it can mean one rule says “never disclose internal state” while another says “provide full diagnostic context”, or one rule says “ask for approval before privileged action” while another says “resolve the issue automatically if possible”. The model will often pick the most recent or most local instruction. That is enough to create a leak.

The fix is to make conflict detection explicit and routine. Every time a new rule is proposed, check what it overrides, what it narrows, and what it might accidentally reopen. If the answer is uncertain, the rule should not be merged yet. Security governance gets much easier when the team treats ambiguity as a stop sign instead of a place to add more explanation.

Conflict review should include old examples too. Stale examples often teach behavior that the current policy no longer allows.

4. Sensitive instructions should be versioned like access control

When a rule affects confidentiality, permission, or escalation, it should not be edited like a casual note. It should have an owner, a version history, and a rollback path. That way, if a change widens the boundary too much, you can restore the prior state without guessing where the behavior changed. Security systems live or die by reversibility.

Versioning also makes review easier. You can ask what changed since the last approved state, whether the change was tested against the regression set, and whether the new rule is compatible with existing approvals. Without version tags, all of that becomes memory work, which is a bad place to put security.

A secure skill should never depend on someone remembering “the old wording used to be safer”.

5. Human approval belongs in the path of privilege

Some changes are too sensitive for fully automatic repair. Any instruction that weakens a refusal, expands tool permissions, broadens access to a dataset, or changes how secrets are handled should require human approval. The approval is not just about compliance. It is about making sure a local fix does not silently become a permission upgrade.

Approval should ask concrete questions: What boundary changed? Is the change narrower or wider than before? Does it align with the reference policy? Does it alter the rollback story? The more concrete the review, the less likely it is to let an unsafe but well-written patch through.

In practice, the safest flow is simple: automatic repair can draft, but humans must authorize security-relevant merges.

6. Reference files are part of the security perimeter

Security rules are only as trustworthy as the files they point to. If the main skill says one thing and the reference file says another, the model gets a second path to interpretation. That second path can be enough to undo the intended boundary. For this reason, reference consistency is not editorial housekeeping. It is security maintenance.

Whenever a secure rule changes, check the reference file, the example set, and the rollback notes. If those sources do not agree, the boundary is not yet stable. In a security context, “mostly consistent” is not a helpful state. It invites selective reading.

The safest setup is to make one file authoritative for policy, another for examples, and another for operations, then keep the links tight and deliberate.

7. Positive behavior should describe safe refusal, not just prohibition

Security guidelines are often written as long lists of forbidden actions. That is not enough. The model also needs to know how to refuse cleanly, how to escalate, and how to continue safely after refusing. If the skill only says “do not reveal” or “do not bypass”, the agent may still fail to give a useful answer. A good secure rule gives the safe alternative.

For example, instead of only saying not to expose internals, say how to offer a high-level summary, how to ask for authorization, or how to redirect to an approved workflow. That way, refusal is not dead end behavior. It is controlled behavior.

Safe alternatives reduce the temptation to improvise around the boundary.

8. Build regression cases for boundary leaks

Security governance needs boundary regression tests. These are not generic success cases. They are small adversarial probes: requests that try to elicit secrets, bypass approvals, expand tool scope, or exploit vague exceptions. If those probes start succeeding after a skill update, the update should not be merged.

Regression cases also help distinguish a wording improvement from a policy mistake. Sometimes the same change that makes the text smoother also weakens the fence. Only the test can tell you that. Good security maintenance therefore treats regression as the last line before merge, not as an afterthought.

Without these tests, every cleanup carries a hidden chance of becoming a permission leak.

9. Budget exceptions the same way you budget privileges

Exception creep is one of the classic ways secure instruction sets become unsafe. If every incident gets its own permanent carve-out, the exception list soon looks like the actual policy. A budget helps. Limit the number of active exceptions, require expiration dates, and force review when the count rises. This keeps emergency logic from becoming normal behavior.

Budgets should be visible. If a repair wants to add a new exception, the system should ask which older one can be removed or consolidated. That question alone prevents a lot of drift. Over time, the exception budget becomes a strong signal of whether the secure surface is improving or rotting.

Security gets easier when exceptions have to fight for space.

10. Rollback matters more in security than in almost any other area

A bad security patch is more than a formatting problem. It can expose access or weaken refusal behavior. That means rollback must be fast, obvious, and rehearsed. If the team cannot restore a previous approved state quickly, the cost of a mistaken merge becomes much higher. In practice, the rollback path should be documented beside the patch itself.

The existence of rollback also changes how people write patches. When they know they can revert, they are more willing to keep changes small. Small changes are easier to audit, easier to test, and less likely to hide a surprise. That is exactly the behavior a security process wants.

No secure skill should depend on the hope that the next edit will be harmless.

11. A secure review sequence should be boring and repeatable

The best review sequence is also the least dramatic: detect the change, classify the risk, compare policy files, run boundary regression, check approval requirements, and only then merge with a version tag. If a step is missing, the sequence is incomplete. If a step is skipped because the patch “looks fine”, the process is already failing.

That kind of boring discipline is exactly what keeps a skill from becoming a security liability. The review does not need to be clever. It needs to be dependable. Dependable review is what lets security boundaries survive long periods of automatic repair without turning into a pile of exceptions.

In this space, slower often means safer, and safer usually means easier to operate later.

12. The point is not more text, but more control

When security boundaries are clear, the skill can actually be shorter. The main document can state the policy, the reference file can carry the details, the examples can teach the shape of safe behavior, and the regression set can prove the fence still works. That division of labor is much safer than stuffing everything into one giant file and hoping the model sorts it out.

So the end goal is not a larger instruction surface. It is a controlled one. Clear boundaries, visible approvals, consistent references, tight exception budgets, and reliable rollback do more for safety than extra warnings ever will.

Security in agent skills is mostly an engineering habit: keep the fence visible, keep the rules versioned, and never let convenience outrun review.