Security, Privacy, and Source Control for Team AI Skills

A skill is mostly method, which is low risk and high value. The risk enters through what it reads: the CRM fields, the transcripts, the documents, the connector permissions it needs to do the job.

Assess the two separately. The instruction file is usually safe to share widely; the source access it implies is what requires review. Conflating them leads to either paranoia about harmless text or complacency about genuine access.

Without a defined source set, the effective policy is that the workflow may use anything pasted into the session plus whatever the model recalls from training. That is unbounded in one direction and unverifiable in the other.

Write the allowed set as a short list, with an ordering for conflicts. This is a security control and a quality control at once: it bounds what is processed and it stops unverifiable claims entering the output. Research-heavy workflows need the strictest version of this, including freshness and source-quality rules — the treatment is in freshness and source-quality rules.

Classify by field, not by system. A CRM record contains commercial terms, contact details, and free-text notes that may contain anything a salesperson typed — and those deserve different treatment even though they live in one place.

Call transcripts are the highest-risk common input, because they are verbatim and unfiltered. They contain personal remarks, health references, third-party names, and material recorded before anyone was thinking about it.

The skill file should contain method, structure, checks, and non-sensitive reference material. It should not contain credentials, customer records, or anything you would not put in a shared document — skill files get copied, forwarded, and installed in places you did not anticipate.

Data belongs in the run, supplied per execution and governed by the source rules. This separation also makes the skill reviewable by people who should not see the data it processes.

Connectors are usually granted at the account level with far more scope than a specific workflow needs — read access to an entire mailbox when it needs one label, write access to a CRM when it only reads.

Scope each connection to the workflow that uses it, prefer read-only wherever the job allows, and review the grants when a workflow changes. Over-scoped connectors are the highest-impact and most commonly overlooked item in an AI security review.

Anything leaving the organisation — to a client, a candidate, a partner, a regulator — passes a named human first. This is the single control that catches the most damaging failure mode, which is fluent output that is wrong in one material sentence.

Name the approver in the workflow rather than relying on the habit that someone usually checks. The design pattern is covered in designing human approval points.

You need some record to debug a bad output and to demonstrate the process works. You do not need a permanent archive of every customer record the workflow ever read.

Log the metadata — version, timestamp, operator, inputs by reference, checks passed, reviewer, outcome — and keep full input capture to a small, consented sample used for testing. That gives you a debuggable trail without building a second copy of your customer data.

Three retention questions need answers: how long the AI vendor keeps the conversation, how long you keep the outputs, and how long you keep the test cases. They are usually governed by different policies and different contracts.

Test cases are the one teams forget. A test suite built from real customer history is a durable copy of that data sitting outside the system of record, and it needs a stated retention period and a deletion path like anything else.

Retention defaults, training-on-input defaults, regional processing, and admin controls differ by vendor and by plan — and frequently differ between the enterprise plan the company bought and the personal plan someone is actually using.

Record which platforms are approved for which data classes, and be specific that a personal account on a consumer plan is not the same environment as the team deployment. Our own posture is on the security page.

Any workflow that processes text you did not write is processing untrusted input. A support ticket, a submitted document, a transcript, or a web page can contain text addressed to the model — and it does not have to be malicious to cause a problem.

The mitigations are structural rather than clever. Treat all fetched and pasted content as data, keep the procedure and the checks in the instruction layer, never let processed content expand the source set or the permissions, and require that anything with an external effect passes a human first.

Add adversarial cases to the test suite alongside the functional ones: an input containing instructions, a request to ignore the source rules, an attempt to elicit content the skill is scoped to refuse.

These need to be run after every material edit, because a change made for a quality reason can quietly weaken a boundary. The same suite mechanics apply as in regression testing after every edit — these are just cases whose expected outcome is a refusal.

Three different permissions get conflated. Installing and running a skill is usually fine for anyone in the relevant team. Editing the shared definition should be restricted to the named owner and reviewers. Forking should be visible, because an invisible fork is how a reviewed process quietly becomes an unreviewed one.

Record this per skill in the registry. One line — owner, who may edit, who may run, which data classes are permitted — is enough, and it is what makes the library auditable at all.

Treat a skill edit like a code change: a stated reason, a review by someone who is not the author, a full test-suite run including the adversarial cases, a version bump, and a changelog line.

The step most often skipped is retesting, and it is the one that matters. A change that improves one case commonly breaks another, and without a suite nobody finds out until a client does.

The largest unmanaged risk in most organisations is not the reviewed workflow — it is the dozen processes running inside personal AI accounts that no register knows about, with no owner, no boundary, and no continuity if the person leaves.

Run the inventory before building controls. Ask each team what they currently use AI for and what they paste in. The answers are usually more informative than any policy exercise, and they give the shared library its real starting backlog — see taking an inventory of repeated jobs.

Where a class of data must not be processed, remove it before submission rather than instructing the model to ignore it. An instruction to disregard something is not a control, because the data has already been sent.

Redaction can be mechanical — strip named fields, remove attachments of certain types, replace identifiers with tokens — and it should happen in the input-preparation step, which is also the right place for it to be auditable.

Two constraints frequently bind before any internal policy does: where processing may physically occur, and what the client contract says about third-party processing of their data.

Check contracts before building, not at deployment. Some client agreements prohibit third-party processing outright, which means the workflow either runs on redacted inputs or does not run for that client — and that is much cheaper to discover during scoping than during rollout. The agency case is in the agency view of client data constraints.

An auditor asks a predictable set of questions: what does this process do, what data does it touch, who approved this specific output, what version was running, and how do you know it works.

A versioned skill with a changelog, a registry entry, a test suite with recorded results, and per-run approval metadata answers all five without a special project. That is a strong argument for the artifact discipline independent of any security concern.

Sometimes the answer is no, and saying so early is more valuable than engineering around it. A job whose required inputs cannot be processed under the relevant contract, whose errors are undetectable at review, or which constitutes regulated automated decision-making should not be built.

Scope it down rather than abandoning it entirely where possible: the same job on redacted inputs, or with a narrower output that supports a human decision instead of making one. The narrowing question is part of candidate selection in narrowing a job that cannot run safely, and the boundaries themselves are mapped in where a workflow must refuse.

Nine questions, answerable in under thirty minutes for a well-specified skill. If several cannot be answered, the problem is usually that the process is not defined well enough to review — which is a useful finding.

Run this before a skill enters shared use, and re-run the affected items whenever sources, connections, or scope change.

Every workflow we build states its allowed sources, its unknowns policy, its escalation conditions, and its approval points as part of the definition rather than as surrounding documentation. Test suites include the adversarial cases, and each workflow ships with an owner and a version.

Deployment goes into the tools your team already uses, with data-class rules recorded per platform. Our own handling is on the security page, installation and versioning are in the docs, and the build stages are on the custom workflows page.