Before You Turn On an AI SRE Agent: Where Your Code and Logs Actually Go

AI incident agents are everywhere now. Your monitoring vendor has one, your error tracker has one, and a few startups pitch nothing else. The promise is the same: point it at your production data and it will tell you what broke and how to fix it.

The tools are often genuinely useful. But there’s a question most teams skip on the way to the “Enable” button:

To find your root cause, what does this agent need to read, and where does that data go?

This post is a plain-English guide to that question, for CTOs, security leads, and anyone who’ll be asked about it in the next vendor review.

What an AI root-cause agent actually needs

To be useful, an agent needs context. Not a summary — the raw material your engineers would look at:

Input	What it can contain
Stack traces and errors	File paths, function names, sometimes variable values
Logs	Customer emails, IDs, IP addresses, request bodies, occasionally tokens that shouldn’t be there
Traces	Full request paths, database queries with parameters, internal hostnames
Session replays	What a real user saw and typed on screen
Source code	The code around the failing line, recent diffs, sometimes whole files
Config and deploy metadata	Service names, environment variables, infrastructure layout

Put together, that’s one of the most sensitive data sets your company has. It’s often more sensitive than your production database, because it combines customer data with a map of how your system works.

The data path nobody draws for you

When a vendor says “our AI analyzes your incidents,” there are usually three hops, not one:

1. Your environment → the telemetry vendor. Your logs, traces, and errors are already sent to their cloud. You probably reviewed this hop when you signed the contract.
2. Telemetry vendor → their AI orchestration layer. The agent gathers context, builds prompts, and sometimes pulls in your source code from a Git integration you approved separately.
3. AI orchestration → a model provider. The prompt, including your code and logs, is sent to a large language model run by a third company, under that company’s data terms.

Hops 2 and 3 are the ones that rarely get reviewed. They’re often turned on by a product update or a toggle, not a procurement process.

12 questions to ask before you enable any AI agent

Use these in your next vendor review. A good vendor will answer all of them in writing without hesitation.

Where the data goes

1. Which model provider (or providers) process our prompts?
2. In which regions is inference performed?
3. Is our source code sent to the model? Whole files, or only snippets? Who decides?
4. Are session replay contents or log lines with customer data included in prompts?

What happens to it 5. Are our prompts or outputs used to train any model, yours or the provider’s? 6. How long are prompts and responses retained, and where? 7. Is there a zero-data-retention agreement with the model provider, and does it cover us?

Control and visibility 8. Can we redact or block specific fields (emails, tokens, PHI) before they reach a prompt? 9. Can we see an audit log of every prompt sent on our behalf? 10. Can we use our own model account and key instead of yours? 11. Can we turn AI features off per environment, for example on in staging and off in production?

Contracts 12. Is the model provider listed as a subprocessor in your DPA, and will you notify us when that list changes?

Note: If the answer to #10 is “no,” every other answer depends on trusting two vendors’ policies instead of one. That’s a real risk to weigh, not an automatic dealbreaker.

What this means for compliance

None of this is legal advice. Talk to your compliance team or counsel about your specific obligations. But here’s how these questions usually show up:

SOC 2. Your auditor will want to see that vendors handling sensitive data are assessed, and that subprocessors are known. An AI feature that adds a new model provider adds a new subprocessor to your vendor management scope.

HIPAA. If logs, traces, or replays can contain protected health information, every party that processes them typically needs to be covered by a Business Associate Agreement. That includes the model provider at hop 3, not just your telemetry vendor.

GDPR. Personal data in logs (emails, IPs, user IDs) sent to a model provider is a processing activity, and possibly an international transfer. You’ll need to know where inference happens and whether it’s on your subprocessor list.

Internal policy. Many companies now have an AI usage policy saying source code can’t be sent to third-party models without approval. An agent that pulls in your Git history may fall under it, even if no one thinks of it as “using AI.”

Four architectures, compared

Roughly, every AI incident tool today fits into one of these:

Architecture	Where telemetry lives	Where AI inference runs	Whose model terms apply
SaaS + vendor AI	Vendor’s cloud	Vendor’s chosen provider	Vendor’s and provider’s
SaaS + your key	Vendor’s cloud	Your model account	Yours, but data still passes through vendor
Your cloud + vendor AI	Your cloud	Vendor’s chosen provider	Vendor’s and provider’s
Your cloud + your key (BYOC + BYOK)	Your cloud	Your model account	Yours

The first row is the most common and the easiest to start with. The last row is the only one where the data path stays inside contracts you already control.

A practical rollout plan

You don’t have to choose between “never use AI” and “turn it all on.” A sensible path:

1. Classify first. Decide which data can go into prompts (stack traces, service names) and which can’t (PHI, payment data, credentials).
2. Scrub at the source. Remove sensitive fields in your OpenTelemetry Collector before they’re stored anywhere. That protects you whatever AI tool you add later. (Our OpenTelemetry setup guide includes a scrubbing config.)
3. Start in staging. Turn on AI analysis for non-production environments and review what the prompts actually contain.
4. Require an audit trail. If you can’t see what was sent, you can’t answer the auditor’s question.
5. Prefer your own key. Using your own model account means the provider’s terms are ones you negotiated, and usage shows up on your own bill and logs.

How Modulis handles this

We built Modulis for teams who’d get asked these questions, including fintech and healthtech teams with data residency requirements.

• BYOC: the whole Modulis application deploys inside your own cloud. Logs, traces, errors, replays, and code context are stored and analyzed there.
• BYOK: AI root cause analysis runs on your LLM key, under your account with your chosen provider. Your code and telemetry never leave your environment.
• One data path to review: because telemetry and AI analysis run in the same environment, there’s no hidden second or third hop to approve.

Or, shorter: your cloud, your model — data never leaves either.

The bottom line

AI incident agents are worth using. They’re fast at the context-gathering part of an incident, which is the part that takes the longest. But they only work by reading your most sensitive data, so the architecture matters as much as the model.

Before you click “Enable,” draw the data path. If you can’t draw it, ask the vendor to.

---

Want to see a BYOC + BYOK setup in practice? Start free in your own cloud, or book a 20-minute walkthrough with your security lead in the room.