Home / Articles / A policy for every skill / Versions / v1.1.0
A policy for every skill: what changed in v1.1.0
From v1.0.0 (2026-10-14, 611ba354e) to v1.1.0 (2026-10-14, c3de98c26), paragraph by paragraph.
0 paragraphs added, 0 removed, 16 changed in place, 32 unchanged. About 1 words added and 4 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
# A policy for every skill: Seana Turner'sfriend's natural-language control for agent skills, the behaviour policy behind it, and using models to need them less
Summary: I was with mya friend Sean Turner this week, talking about agent behaviour policies, and he described something he built that I think is great. It is a natural-language control policy for agent skills, and a CI pipeline that checks every skill contributed to an organisation-wide repository against it before hundreds of developers pull it down to their machines. Is it safe, secure, well documented, usable, understandable by the model and understandable by people. And the part that makes it more than a linter: it reads the skill in its context. A skill that turns internal documentation into a LinkedIn post has no untrusted input to worry about; a skill that pulls content off the web is handling untrusted text, and should treat it as data, not obey it. It sits beside a security scan, not instead of one: the question is operational, is this the right way to give this skill to our workforce. That is an agent behaviour policy for a skill: the mandate is what the skill is for, the reach is everything it touches, and the gap is the risk. A control written in natural language is hope-based security, better than nothing and not enough on its own. Sean'sHis next step is the one I keep coming back to: use an agent to write deterministic rules that follow the natural-language control, and keep the description, not the code, as the canonical version. Change the description, regenerate the code. Using models to need them less. And in a common ontology, a whole catalogue of skills becomes one graph, where the dangerous combinations are a query.
3 unchanged paragraphs, under In short {#in-short}
• SeanA Turnerfriend built a control for them.** A natural-language policy and a CI pipeline: is a contributed skill safe, secure, documented, usable, and understandable by the model and by people.
6 unchanged paragraphs
What Seanmy friend built {#built}
I was with mya friend Sean Turner this week, talking about agent behaviour policies, and he described something he had built that I liked a lot. He has a different name for it: a natural-language control policy for agent skills.
The setting is an organisation with an organisation-wide repository of skills, the packages of instructions and reference material that an agent loads to learn how to do something. Anyone can contribute one, and once it is merged, hundreds of developers can pull it down to their machines and use it. Sean'sHis control is a policy written in plain language about what a skill must be before that happens, and a CI pipeline that checks every contribution against it: is it safe, is it secure, is it well documented, is it usable, is it understandable by the model that will load it, and is it understandable by the people who will review and maintain it. In his words, does it make sense as a reasonable skill.
1 unchanged paragraph
And it is complementary to a security scan, not a replacement for one. A scanner asks whether a skill contains something malicious. Sean'sHis control asks something more operational: is this the right way to contribute this skill to our workforce, given what it will touch when hundreds of people run it.
3 unchanged paragraphs, under Skills are the new dependency {#dependency}
The public tooling for reviewing skills is arriving too, and it shows where the gap is. MongoDB's guide to reviewing an agent skill describes a structural validator that "runs in CI and produces pass/fail results", and a review skill that "optionally uses an LLM judge to score content quality across multiple dimensions": clarity, actionability, token efficiency, scope discipline, directive precision, novelty. That is a good quality bar, and none of those dimensions asks where the skill's inputs come from. The guide says as much about the hardest part: "No automated tool currently reasons across skill boundaries." Sean'sHis control asks the question the quality bar leaves out, which is the one that decides whether a skill is dangerous.
2 unchanged paragraphs, under It is a behaviour policy for a skill {#abp}
When Seanhe described it, I recognised the columns. An agent behaviour policy describes one agent in one setting by its mandate, what it is for; its reach, everything it can actually touch; the gap between the two, which is the risk; and the barrier in front of each row of the gap. Describe a skill that way and the context question answers itself.
4 unchanged paragraphs, under Hope-based security, and why it is still worth writing {#hope}
But I agree with Seanhim that it is far better than not having it. A written control is the only place the intent exists. It is what a reviewer reads, what a model can check a skill against, and what the deterministic rules are written from. Without it, there is nothing to enforce, only code that nobody can explain. With it, the question becomes how much of it can be wrapped in something that does not hope.
1 unchanged paragraph, under Use models to need them less {#codify}
That is where Sean'shis next step comes in, and it is the part of the conversation I liked most. Use an agent to write deterministic rules that follow the natural-language control. For example, a skill that declares it reads the web gets a rule that checks it routes fetched content through a step that treats it as data. A skill that can post externally gets a rule that it has a human step before it does. The model reads the control once and writes code; from then on, the code runs, the same way every time, at no model cost per run.
3 unchanged paragraphs, under A catalogue is a graph {#graph}
The last piece is what happens at the scale Seanhe is working at: not one skill, but hundreds, contributed by different people, describing themselves in different words. My approach to that is to bring them to a common ontology, the way fractal semantic graphs do: every skill described by the same columns, mandate, reach, inputs and their trust, barriers, as nodes with named edges, while each skill keeps its own text.
3 unchanged paragraphs, under From policy to licence to insurance {#licence}
A skill with a policy, checked at contribution and enforced where it runs, is the smallest version of that whole chain. SeanHe has built the first link.
1 unchanged paragraph, under What this does not claim {#limits}
• Sean'sHis tool is described from a conversation.** I have not seen its code, and I could not find it published; the details are his, as he told them, and any errors are mine.
4 unchanged paragraphs
If you are running an organisation-wide skills repository, or you have built something like Sean's,his, write to agent@riskmandate.ai.
1 unchanged paragraph, under Where this comes from {#sources}
A conversation with Seana Turnerfriend on 14 October 2026, recorded as a voice memo of mine, and written up by this site's agent in the voice of this site; the argument and the editorial responsibility are mine,mine; the tool and Sean'sits workdesign isare credited to him.his. MongoDB, How to Review an Agent Skill; AWS, Policy in Amazon Bedrock AgentCore; Simon Willison, The lethal trifecta for AI agents, 16 June 2025. All read on 14 October 2026.