Every organization evaluating an AI-driven delivery partner eventually asks the same question: what happens to our code and data once an AI tool touches it. This page explains how Keyhole answers that question in practice, covering which AI accounts we use for client work, when model training is turned off, how a client’s own contract can override our defaults, and the guardrails we put around AI agents that write or execute code.
Last reviewed: September 2026. AI vendor settings and terms change often, so we seek to review this page regularly rather than treating it as a one-time policy.
Which AI Accounts We Use for Client Work
Keyhole consultants work from Keyhole- or client-provisioned AI accounts by default. These are business, enterprise, or API-tier accounts that come with an agreement that inputs and outputs are not used to train the vendor’s models, and they’re the preferred option for every engagement.
A personal/individual AI account is a permitted fallback only after model training has been manually disabled on that account, following the vendor’s current opt-out steps. Turning off one training toggle is not always enough. For OpenAI tools, for example, the ChatGPT data control, the Codex full-environment setting, and the account-wide privacy portal opt-out are three separate switches, and all three have to be off before the account touches any work-related data.
When a Client’s Contract Sets Different Terms
Before any AI tool touches client-owned code or data, we check whether that client’s master services agreement or statement of work restricts AI tool use or dictates specific approved tools. Where a client’s contract is stricter than our internal defaults, the contract governs, not the other way around.
In practice, that means:
- If a client’s contract prohibits AI tool use, we don’t use it on that engagement.
- If a client’s contract is silent or restrictive, only Keyhole- or client-provisioned accounts touch that client’s code or data.
- A personal account, even with training disabled, is only used on client-owned code or data when the client’s contract explicitly allows it.
| Account Type | Trains on Inputs by Default | When We Use It |
|---|---|---|
| Keyhole- or client-provisioned account (business, enterprise, or API tier) | No | Default for all client work |
| Personal account, training disabled | No, once disabled | Non-client work, or client work only where the client’s contract permits it |
| Personal account, training left on | Yes | Never used for Keyhole or client work |
How We Govern AI Agents That Write or Execute Code
Agentic AI tools raise a different set of questions than a chat assistant, because an agent can take actions, not just generate text. Our internal policy treats agent access as something to be granted deliberately, not assumed:
- Scoped, time-limited access. An agent gets the minimum access a task requires, for as long as that task takes, not standing access to production systems or credentials.
- The same review as any other change. Code an agent writes or modifies goes through the same pull request review as code a person writes. There are no direct pushes to protected branches and no autonomous production deployments.
- A human approval step for high-impact actions. Deployments, deletions, external communications, and financial transactions require explicit human sign-off before an agent can take them.
- No acting on embedded instructions. An agent treats content it reads, such as text in a file, webpage, or email, as data to process, not as commands to follow.
- Auditable by design. We preserve agent logs and transcripts for anything that touches production, client data, or external systems, and the person who initiated an agentic task is accountable for everything that task and any sub-agents it delegates to actually did.
What This Means When We Build Agentic AI Systems for You
The same discipline applies to the agentic AI systems our consultants design and build for clients, not only to how we use AI tools internally. When an engagement includes building an agent for you, we design in scoped permissions, human approval gates for high-impact actions, and defenses against prompt injection from the start, and we follow your organization’s AI governance requirements wherever they’re stricter than our own.
Questions Worth Asking Any AI-Driven Development Partner
Most vendors in this space can describe their AI tooling. Fewer can answer these questions specifically, and we’d rather you ask us directly than take a services page at its word:
- Who owns the code an AI agent generates during our engagement, and is that ownership unqualified?
- Which AI services touch our repository, and do they run under terms that exclude training on our data?
- What happens if our contract’s data handling requirements are stricter than your internal default?
- What access does an AI agent have to our production systems, and who approves it?
- Has your team delivered under our specific regulatory framework, not just a list of acronyms on a page?
Questions About This Policy?
If you have questions about how we handle AI tools and data on an engagement, or you’re evaluating Keyhole and want specifics for your contract, contact us and we’ll walk through it directly.