VP Engineering Wanted to Deploy AI Coding Tools. The Security Team Had 24 Weeks of Questions.

"I gave our developers an AI coding assistant. The security team nearly mutinied." That headline from a 2026 CIO article described an experience that most VPs of Engineering at companies over 200 people have had in some form: AI coding tools that work well in pilots run into a security review that takes months, produces restrictions that limit the useful features, and sometimes ends with a rejection that sends the team back to square one. The security team is not wrong to raise the questions. The problem is that per-developer AI tools were not designed to answer them.

What security teams actually object to

Security objections to AI coding tools are not vague. They are specific, answerable questions about data flows, access control, model governance, and audit capability. The problem is that most per-developer AI tools cannot answer them:

Security team objections to AI coding tools:
  Data egress:
    "Code leaves the network for embedding / inference"
    Concern: proprietary IP, regulated code, trade secrets

  Access control:
    "Any developer can connect any codebase"
    Concern: no RBAC, no data classification enforcement

  Model governance:
    "Developers can use any model they choose"
    Concern: no approved model list, no version pinning

  Audit:
    "No log of what AI read or produced"
    Concern: compliance, incident investigation, SOC2

  Supply chain:
    "AI can be prompted to behave maliciously via input"
    Concern: prompt injection via user-controlled content

Each objection corresponds to a specific risk that the security team is responsible for. Data egress is an IP and compliance concern. Access control is a data classification concern. Model governance is a supply chain concern. Audit is a compliance and incident response concern. These are legitimate requirements that every other production system at the company satisfies — and that per-developer AI tools systematically cannot, because they were designed as individual tools, not as enterprise infrastructure.

What the procurement process looks like in practice

For a VP of Engineering trying to get AI coding tools approved at a company with a real security function, the timeline is painful:

Typical enterprise AI coding tool procurement:
  Week 1:  VP Engineering requests approval for Cursor/Claude Code
  Week 2:  Security team receives request, begins review
  Week 4:  Security team asks: "Does code leave the network?"
  Week 6:  Tool vendor responds with documentation
  Week 8:  Security team escalates to Legal re: data processing
  Week 12: Legal requests DPA (Data Processing Agreement)
  Week 16: Vendor DPA returned, Legal reviews
  Week 20: Security approves with restrictions
  Week 22: Restrictions prevent the primary use case
  Week 24: VP Engineering re-scopes the request

Six months to approve a tool that your developers have been using on personal accounts for a year. This experience is common, documented, and avoidable — but only if the tool being reviewed can actually answer the security team's questions. Most per-developer AI tools can answer some of them with vendor documentation. They cannot answer the ones that require organizational infrastructure to exist: audit logs that do not exist, access controls that are not enforced, model governance that depends on developer self-discipline. This is why CISOs block Cursor — not because they are anti-AI, but because the tool is not answering the questions.

What per-developer tools can and cannot answer in the security review

The security review checklist has five main categories. Per-developer AI tools handle the first one partially, struggle with the second and third, and have no answer for the fourth and fifth:

What blocks each security concern:
  Data egress:       per-tool configuration + vendor assurances
  Access control:    manual process (tell developers which repos)
  Model governance:  honor system (hope developers use approved models)
  Audit:             none (per-developer sessions, no org log)
  Supply chain:      none until an incident demonstrates the risk

The audit gap is particularly significant. Compliance frameworks — SOC 2, ISO 27001, HIPAA, FedRAMP — all require evidence that systems with access to sensitive data maintain audit logs. A per-developer AI tool running on a laptop with a personal API key has no org-level audit log by design. It is architecturally incompatible with this requirement.

What managed runtime changes in the security review

A managed AI runtime is designed to answer the security checklist by construction:

What managed runtime provides for security review:
  Data egress:       repo-level authorization, no ad-hoc access
  Access control:    RBAC by team/role, org-administered
  Model governance:  model allowlist, version pinning, no shadow models
  Audit:             full session log, queryable
  Supply chain:      egress controls, context boundaries, anomaly detection

  Result: security review answers the checklist in one meeting,
  not a 24-week procurement process

Kognita's managed runtime provides RBAC access control, an approved model list, a full audit log, and scope controls for codebase access. When a security team asks "who can access which repos?" the answer is a configuration page, not a process that relies on developer discipline. When they ask "what is logged?" the answer is a structured log format, not "nothing, it runs locally."

The VP Engineering's situation

The VP Engineering who wants to deploy AI tools at scale is caught between developers who want them now and a security team whose objections are legitimate. The path through is not to argue with security — it is to use a tool that answers security's questions. When the tool can answer "yes, there is an audit log" and "yes, access is RBAC-controlled" and "yes, models are governed by an allowlist", the procurement process compresses from six months to a security review meeting.

Final take

Security teams blocking AI coding tools are not an obstacle to work around — they are answering the right questions about a tool that was not designed to be deployed enterprise-wide. The VP Engineering's job is not to win an argument with security. It is to bring a tool to the review that can answer the questions.

Managed runtime passes the security review because it was built to pass it — not as an afterthought, but as the core design. Enterprise AI deployment requires enterprise AI infrastructure, and the procurement timeline reflects which infrastructure is present.