12 Security Questions Every AI Coding Agent Needs to Be Able to Answer

Originally published on the Kimchi blog by JJ Lim.

Your security team has a questionnaire.

Every vendor gets it, and most AI coding vendors answer it with a trust portal link and a meeting request, not with answers. That's how a two-week review often becomes a two-month email thread.

It's worth noting why this review is harder than a normal SaaS review, because an AI coding agent is not simply a chat window. It has access to read your repository, hold a model of your codebase in context, execute shell commands, and loops: plan, edit, run tests, read the failure, edit again. A single task generates hundreds of model calls, and agentic workloads consume up to 1,000x more tokens than chat queries. So the data path is continuous rather than transactional, there's an execution surface somewhere running commands under some identity, and state accumulates: sessions, compacted context, and work history are data too, the data most questionnaires forget to ask about.

That leaves security with three questions to answer: where does the code go, what controls each request along the way, and where do the agent's commands run.

This post is going to unpack these questions from the perspective of Kimchi.dev - our coding agent that was built with these inherent problems in mind.

Kimchi.dev was built intentionally to separate the system into three components, and your deployment mode determines where each runs:

1. The inference endpoint controls where the model runs, and therefore where your code and prompts physically go.
2. The enforcement proxy controls what happens on every request: authentication, policy, budget caps that enforce when configured, and the audit trail. Every request from every agent passes through it. There is no bypass path.
3. The execution environment controls where the agent reads files, writes code, and runs commands.

This means that because the components are separate, you choose who runs them, and that choice shapes the answers to security's questions. In serverless mode, Kimchi.dev manages inference. In self-hosted mode, all three components run inside your infrastructure, in your Kubernetes cluster, with support for 50+ models including open-weight models you host yourself.

Almost every answer below reduces to "which component is involved, and who runs it."

Here are the twelve questions security actually sends, each answered for Kimchi.dev in plain language you can paste into the questionnaire response unedited. Where the honest answer is "not yet," we say not yet.

This post on the Dynamic Inference Boundary takes a deeper dive on how this works under the hood with Kimchi and other ecosystem tooling.

1. Where does our data reside?

The data resides wherever you put the inference endpoint.

In self-hosted mode, models run in your VPC or on-prem cluster, and session state and traces live there too, so code stays in your infrastructure and jurisdiction, with no second location to audit. In serverless mode, requests go to Kimchi-managed endpoints in documented regions.

2. What egresses our network?

In self-hosted mode, the inference endpoint, enforcement proxy, and execution environment all run inside your network, so the coding path, the one carrying source code, requires no outbound calls to Kimchi.dev. Control-plane traffic such as licensing is a separate, documented, inspectable stream, so your team verifies what it carries rather than trusting us.

3. How long is our data retained?

In self-hosted mode, prompts, completions, and traces are stored in your infrastructure under your retention policy; Kimchi.dev never holds them. In serverless mode, request data is retained for operations and billing for a documented window, and deletion covers derived artifacts such as session summaries, propagating to backups on a documented schedule.

4. Is our data used to train models?

No. Kimchi.dev does not train on customer data, ever. Not prompts, completions, source code, or derived telemetry, and the commitment includes fine-tuning, evaluation sets, and "service improvement," where exceptions usually hide. It holds across every deployment mode and every model behind the platform, contractually. There is no opt-out checkbox because there is nothing to opt out of.

5. How does the agent handle secrets?

The execution environment runs where you choose, so the agent reads only what its runtime identity can read. Scope its credentials like a CI runner's: least privilege, short-lived tokens, no shared service accounts. Because agents can be steered by content they read, containment comes from the environment boundary and controlled egress, not from model behavior.

6. Do we get audit logs?

Yes, and they come from the architecture, not a reporting feature. Every request from every agent traverses the enforcement proxy, producing a per-request trace: who called, which model served it, token counts, per-user cost. An agent cannot reach a model around the proxy, so the log is the activity itself, not a sample of it.

7. Is there RBAC?

Yes. Roles separate platform administration, policy and budget configuration, and day-to-day agent use, so the person setting spend caps isn't the person being capped, and model allowlists are set by policy owners rather than negotiated per engineer. An engineer-role user cannot exceed the budget or reach a disallowed model; the proxy enforces, it doesn't alert.

8. Is there SSO?

Yes. SSO is supported for enterprise deployments, so access follows your identity provider and every request authenticates against it, not just login. Offboarding severs model access, audit attribution, and budget allocation in one motion, which closes the classic CLI-tool failure mode: a long-lived personal API key that keeps working after the engineer leaves.

9. What's the provenance of the models?

You always know which model served a request, because the proxy records it per request, and no model is silently swapped behind an alias, the way closed-model vendors routinely update checkpoints. In self-hosted mode you can run 50+ models, including open-weight models whose weights you download, verify, pin, and host yourself, so provenance is auditable rather than asserted.

10. What's your incident response process?

Security incidents follow a documented response process with defined customer notification commitments, published in our trust documentation. Architecturally, because every request is proxied and traced in a log you own, scoping an incident is a query rather than an archaeology project: you establish exactly which users, models, and repositories were in the blast radius, on your timeline.

11. What compliance certifications do you hold?

SOC 2 Type II. GDPR and DORA by design. HIPAA-ready architecture, with a BAA available on request. FedRAMP Moderate is in progress, not complete; if you need an authorized deployment today, the honest answer is not yet. We don't currently claim ISO 27001 or PCI-DSS, and won't until we can evidence them.

12. Who are your subprocessors?

A current subprocessor list is published and maintained, and it changes with your deployment choice, which is the part worth noticing. For AI coding tools, the heaviest subprocessors are the model providers, the parties that actually receive source code. In self-hosted mode they leave your data path entirely; in serverless mode, the documented list applies.

Three follow-up questions worth sending every vendor

If you're forwarding this page into a parallel evaluation, these are the follow-ups that separate real answers from trust-portal answers, ours included:

1. Where does the accumulated state live? Residency claims usually cover the inference request and quietly exclude session history, compacted context, and traces, which amount to a detailed map of your codebase. Ask where that state resides, how long it's retained, and whether deletion covers derived artifacts and backups.
2. Can an engineer-role user exceed the budget or reach a disallowed model if they try? If the answer involves the word "alert," the controls are advisory. Reporting features observe; enforcement points gate. Shadow usage through personal API keys exists precisely where there's no enforcement point.
3. When the alias updates, does my change-management process see it? Closed-model vendors routinely swap checkpoints behind a stable model name. For anyone who must answer "what logic produced this decision" in an audit, an unversioned alias is an unanswerable question. Pinned, checksum-verified open weights are a different evidence class.

Why these answers differ from the tools you're already evaluating

If you're running this questionnaire against GitHub Copilot, Claude Code, or Cursor in parallel, the answers to questions 1, 2, 9, and 12 come out structurally different, because the architectures are different:

• GitHub Copilot can't self-host and isn't available on GitHub Enterprise Server, so residency and egress answers are Microsoft's cloud, full stop. FedRAMP and data-resident deployments carry a 10% model multiplier penalty, so meeting the compliance requirement raises the price of every request.
• Claude Code offers no fully self-hosted inference. Even the self-hosted gateway still routes to Anthropic's cloud-hosted models, so the data residency answer ends at Anthropic's infrastructure regardless of where the gateway sits, and Anthropic's documentation states there's no offline or local model support.
• Cursor is cloud-only SaaS. All traffic routes through Cursor's backend, which means the security answer to most of these twelve questions is someone else's architecture. And that architecture can change mid-contract without your approval: Cursor's OpenAI model access is being cut off on November 12, 2026 following its acquisition, changing the upstream half of its customers' data path under them.

None of this makes those tools bad agents. It means that for most of the twelve questions above, their answer is fixed by their architecture, and yours has to be "we accepted that." With Kimchi Coding, the deployment mode is your call, so the answers are too.

The part your security team already suspects

The market spent the first half of 2026 proving that ungoverned AI coding is a liability. One enterprise hit a $500M single-month Claude bill (Axios, May 28, 2026). Microsoft revoked Claude Code licenses running $500 to $2,000 per engineer per month (Axios, May 2026). Uber burned its entire 2026 AI budget by April (Fortune, May 26, 2026). Those read as finance stories, but look at the mechanism: requests nobody could see, attribute, or stop. That is a security issue, and is compounded by the business liability. The same missing control point that let spend run unbounded is the one that would let data move unobserved.

That's why the enforcement proxy alone answers half this questionnaire. Audit completeness, cost attribution, identity-bound access, provenance, incident scoping, budget caps that enforce when configured: they all originate from one architectural decision, that no request reaches a model without passing through a control point you can inspect. Everything downstream of that decision is a query, while everything upstream of it is trust.

Forward this page to your security team, and if they have a thirteenth question, we'll answer that one straight too.

Kimchi.dev is made by the creators of CAST AI. Kimchi Coding runs serverless or self-hosted in your Kubernetes cluster: docs.kimchi.dev · github.com/getkimchi/kimchi

Sources: Axios (May 28, 2026; May 2026), Fortune (May 26, 2026), Anthropic documentation (Claude Code offline/local support), Bloomberg/CNBC/TechCrunch (Cursor acquisition and OpenAI model access cutoff, Nov 12, 2026), GitHub Copilot enterprise documentation (GHES availability, FedRAMP/data-resident model multiplier).