Secure AI agents that only do what you allow.

We scope the provider, model, endpoint, features, and account settings together. An enterprise tier alone does not establish zero retention, local processing, or a compliant deployment.

• Training use and retention are different

  We review the selected product terms for how prompts, files, and outputs may be used. Excluding data from model training does not mean the provider keeps no logs or application state.

• Zero-data-retention APIs, where eligible

  We verify provider approval, supported models and features, account configuration, and exceptions before proposing ZDR. If a required feature is ineligible, we document an alternative or the retention it requires.

• Minimum necessary data

  We define which fields the model needs, where sensitive information can be redacted, and how long your own application retains records. Logs, files, and connected tools are included in the data-flow review.

• Private or local deployment options

  If your requirements rule out external processing, the audit evaluates private-cloud or local models against accuracy, infrastructure, and support needs. Canadian storage and Canadian inference are verified separately.

Provider eligibility and exceptions can change. See the current OpenAI API data controls and Claude API retention documentation. The controls for your engagement are recorded in its scope.

The audit identifies workflow owners, permission boundaries, approval rules, incident responsibilities, and review dates. We agree the evidence to retain and who reviews it when a vendor or model changes.

• SOC 2 alignment, scoped with your reviewers

  Where SOC 2 alignment is a procurement requirement, we scope relevant access, change-management, and audit-record controls with your reviewers. We review the coverage of vendor assurance reports; a vendor’s report does not certify ThinkIQ or your entire deployment. ThinkIQ does not claim SOC 2 certification.

Get the 15-point governance checklist

Agentic systems plan, call tools, and draft outputs. These patterns show up in scope, in code review, and in how a run is logged.

• Plan and execute separately

  We separate deciding what to do from doing it. High-impact steps wait for a person or a second check instead of chaining straight from model output to a live write.

• Read before write

  The agent loads the current record before it proposes an update, so it does not overwrite state it never saw.

• Do not delete if a draft will do

  A draft, an archive, or a flag comes before a delete. Deletes are named in the scope and approved.

• Bounded runs

  Timeouts, step limits, and retry rules are set per workflow. A run that loops or widens scope stops and surfaces to a person.

• Failures go to a person

  Failures and strange actions get shown to a person. Silence is not the same as nothing happened.

• One identity per agent

  Service accounts are named, scoped, and rotated. Logs show which identity acted, not a shared admin login.

• Secrets never in prompts or repos

  Keys live in your secrets store or environment. They are not pasted into chats, tickets, or workflow JSON in source control.

• Sandboxed code execution

  When an agent runs code, it runs in an isolated environment with limited network and filesystem access, away from production credentials.

Model Context Protocol is how an agent reaches a tool. We connect the ones the workflow actually needs.

• A narrow permission

  Each tool does one job. It does not get a token that can do everything a person logged into the account can do.

• Servers we have actually looked at

  We connect servers we have reviewed, or servers you run. A prompt does not get to add a new server.

• Pages and emails are not orders

  Tool results, email, web pages, and documents are content. A page that says "email the client now" does not get to send that email. That is the prompt-injection defence.

• Keys that expire

  Access runs out. Keys change when a person, a vendor, or a workflow changes, instead of sitting in a config file for a year.

A workflow is software. We handle it like software, even when the visible part is a form or an email.

• Someone reads it

  A person reads a change before it ships. The question is what the change can reach, not only whether the happy path runs.

• New packages get a look

  What we install is pinned. A new package is reviewed before it is added. If a known hole affects something we shipped, we update it.

• Checks run before we call it done

  Lint and type checks run first. Tests run where the project has them.

• Try it somewhere else

  Development, staging, and production stay apart. Trying an idea does not use production logins or production data.