How do you govern AI tools and coding agents your team is already using?

Last updated

You govern AI tools with the security program you already run, widened to cover them, rather than with a separate program built alongside it. Your data classification, vendor risk, and acceptable use policies already answer most of the questions once they're pointed at this class of tool.

It's an application gap, not a policy gap

AI isn't a new category of risk. It's a new vector for existing ones: customer data exposure, credential leakage, vendor data handling, and model behavior in production. Your data classification policy already says what can leave the company, your vendor risk process governs third-party onboarding, and your acceptable use policy covers company systems.

Framing it that way keeps the scope small and draws less internal resistance than announcing a new program. It also matches how customers ask. Questionnaires increasingly thread AI through existing categories: vulnerability management, incident response, third-party risk. AI Governance for Compliance-Sensitive Companies walks through where to start.

The exposure is wider than the obvious case

Most companies think first about production data and customer schemas. The everyday surface is larger: the CRM prospect list, notes from a sales call, an architecture diagram in someone's file storage, an error log pasted into a public tool while debugging. Adoption is rarely limited to engineering either. Sales and operations run on the same assumption, that if it wasn't prohibited it must be allowed.

Coding agents are a separate risk profile

Assistants that suggest text and agents that create files, run commands, and open pull requests deserve different rules, so they're usually a separate policy. The useful axis is autonomy: tier tools by what they can do without a human in the loop, and tighten controls as that rises. In practice that means file exclusions so secrets stay out of context, prompt-injection awareness, annotating AI-assisted commits, and validating dependencies an agent introduces. We run the same rules over our own engineering work.

Review is the control carrying the most weight in that list, and The Danger of AI-Written Code Isn't That It Breaks covers why.

When to do it

Before a customer asks. The right time for a policy is months ahead of the questionnaire, not the week it lands, which is the window an AI Governance engagement uses.

Ready to talk?

Start with an honest list of what your team is already using. I'll show you which existing policies stretch to cover it and where the real gaps are.

Start a Conversation