The challenge behind the engagement.
This service is for the AI you rent: managed model and agent services from a cloud provider, and the AI tools your staff sign up for. We review each deployment setting by setting against its data class. Identity: managed identities and scoped roles instead of long-lived keys, plus customer-managed encryption keys where the data demands. Networking: private connectivity with public access turned off. Guardrails: content and prompt-injection filters tuned to each data class. Data use: training opt-out confirmed, human review of your prompts addressed, and the processing region pinned down. Logging: usage and request logs turned on and routed to your monitoring. You receive the current and target state for each setting, the exact change to make, and a retest once it is applied.
For cloud platform owners, security engineers, and compliance leads whose developers have already created AI resources in the cloud, or whose staff use third-party AI assistants under an enterprise agreement. Engage before PHI or CUI reaches a deployment, before a SOC 2 or HIPAA evidence window, or after an account review finds AI resources nobody scoped.
What we do.
What you can use.
Enumerate deployments and their data classes
We start with read access to the accounts and projects that host AI resources, a list of deployments with the data class each handles, and read access to your identity system. We enumerate what exists, including resources created outside the platform team, and agree which settings matter for each data class and which government cloud constraints apply.
Review every setting against its target
For each deployment we record the current and target state: key-based sign-in off and managed identity on, customer-managed encryption configured, public network access disabled with private-only connectivity. We tune filter strength and prompt-injection protection, confirm the right handling where PHI or CUI flows, and route logging to your monitoring. We write the rules as enforced policy so the settings cannot drift back.
Apply changes, retest, and file evidence
Your engineer applies each change in a change window, with us on the call or from the written step-by-step instruction. We retest every applied setting and export the configuration, screenshot, or policy report as evidence for your SOC 2, HIPAA, or CMMC folder, with notes on which models are eligible in a government cloud. Provider approval requests for restricted features are yours to file.
Who it’s for.
When you need it.
- Cloud platform and security teams whose developers already spun up managed AI resources
- Compliance leads who must show how a rented AI service protects regulated data
- Organizations whose staff adopted third-party AI assistants under an enterprise agreement
- Teams operating in government or sovereign cloud regions with per-model eligibility limits
- PHI, CUI, or other regulated data is about to reach an AI deployment
- A SOC 2 or HIPAA evidence window is approaching and configuration must be shown
- A subscription or account review found AI resources nobody formally scoped
- Staff enabled an AI assistant and leadership wants its data handling verified
What the scope can include.
- 01
Identity and keys: managed identities and scoped roles instead of static keys, regular key rotation, and customer-managed encryption keys where required
- 02
Private networking with public access disabled, so the service is reachable only from your own network
- 03
Guardrail configuration: content, prompt-injection, and sensitive-information filters tuned to each data class
- 04
Data use and residency: training opt-out confirmed, provider human review of prompts addressed for PHI and CUI, and the processing region fixed
- 05
Logging: usage, request, and data-access logs turned on and routed to your monitoring, with retention and redaction rules
- 06
Third-party AI tools: single sign-on and automated provisioning, tenant isolation, training and retention terms, subprocessors, data-loss controls, and log export
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
A few AI services in one cloud account handling one kind of data
About 24–40 hoursAI services across several cloud accounts plus one or two staff AI tools, with regulated data
About 56–88 hoursMany AI services across more than one cloud or a government cloud, with a full evidence package
About 110–160 hours- Number of AI deployments and cloud accounts
- Kinds of data involved, such as health or defense information, and the rules they bring
- Staff-facing AI tools under enterprise agreements added to scope
- Government cloud limits and how much audit evidence is needed
Ranges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Setting-by-setting review with current state, target state, and the exact change to make for each deployment
- Private connectivity design and guardrail configuration for each deployment
- Government-cloud eligibility notes per model, with enforced policy rules that prevent the settings from drifting
- Evidence pack of exported configurations, screenshots, and policy reports, with a retest of applied changes
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
Is our data used to train the provider's models, and where is it processed?
It depends on your provider and settings, so we confirm each per deployment rather than trust a marketing page. Most major providers state that your prompts, responses, and tuning data are not used to train their foundation models, but two things still matter: whether the provider retains flagged prompts for human review, which you can often turn off with approval, and the deployment type, which can change where processing happens. We record the evidence for each setting and confirm the provider's current terms during the engagement rather than assuming last year's defaults still hold.
Do we need private connectivity if the application already sits inside our cloud network?
Usually yes. Without private connectivity the AI service still answers on its public address, so a leaked key or a misconfigured identity can be used from anywhere. Disabling public access and adding private-only connectivity makes the service reachable only from your network, and gives you a control an assessor can see. Some features stay private while others still reach out to public addresses, such as certain search or grounding connectors, so we document each exception. Where the provider supports it, you can further restrict which identities and which models the private connection will serve.
- Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile (NIST SP 800-218A)
- AI Risk Management Framework
- Joint Guidance on Deploying AI Systems Securely
- AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems
- OWASP Top 10 for Agentic Applications for 2026
- Model Context Protocol Specification: Authorization
- Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (NIST SP 800-171 Rev. 3)