What Happened
Google described an AI-native approach to infrastructure security: agentic pre-submit scanning embedded directly into the software delivery lifecycle. The system scans every code change across very large repositories before production, using a multi-agent harness called Mantis to identify security issues early and reduce the number of vulnerabilities that reach deployed systems [1].
The notable engineering choice is context. Instead of running generic static analysis alone, the scans use localized threat models built from live codebase metadata and dependency call graphs. A lightweight pre-submit scan is followed by a specialized triage agent that uses AST parsing and call-graph traversal. Google reports false positives around 3%, more than 92% precision, and sub-minute triage for this layer, with nightly post-submit integration scans as a second control [1].
The system also includes an automated fix agent that generates targeted, standards-compliant patches from scan findings and proof artifacts, then submits them for human review. This closes the loop from detection to remediation while retaining developer approval [1].
In parallel, Google’s threat intelligence reporting highlights why this matters now: adversaries are using AI to scale software supply-chain contamination, prompt injection, scanner evasion, credential harvesting, GPU theft, model theft, and unauthorized AI infrastructure usage. Reported activity includes hijacked AI toolkits, exposed tokens used to spin up AI resources, underground markets for AI account credentials, and automated multi-agent attacks that can plan and execute campaigns in hours [2].
Why It Matters to Businesses
Enterprise AI systems add new production risks beyond conventional application security. They rely on model endpoints, prompts, vector stores, orchestration frameworks, plugin/tool permissions, CI/CD credentials, cloud GPUs, and third-party packages. A single exposed token or malicious dependency can become both a data breach and an infrastructure cost event.
- AI increases the blast radius of bad code. Agents can call tools, modify infrastructure, access internal systems, and chain actions. Misconfigured permissions or unsafe code paths can become operational incidents, not just bugs.
- Cloud AI resources are attractive theft targets. GPU access, API keys, model weights, prompts, and source code now have direct resale value. Google reports targeted theft and unauthorized AI infrastructure creation from exposed credentials [2].
- Traditional scanning is too noisy for fast-moving teams. If security tools flood developers with low-quality findings, teams bypass them. Google’s reported precision gains show the value of repository-specific context and automated triage [1].
- Supply-chain risk is now an AI platform risk. AI applications commonly depend on rapidly changing Python, JavaScript, model-serving, data-processing, and orchestration packages. Malicious upstream packages and compromised AI toolkits are increasingly relevant attack paths [2].
- Remediation speed matters. Detection without a fix path creates backlog. Automated patch generation with human review can reduce mean time to remediate while preserving control [1].
Kimbodo Engineering Perspective
The most important lesson is not “use agents for security.” It is put security decisions where the engineering context exists: inside pull requests, build pipelines, infrastructure plans, dependency graphs, runtime telemetry, and cloud identity boundaries.
For production AI platforms, we would treat agentic security tooling as an augmentation layer, not as an autonomous authority. Agents are effective at gathering context, correlating code paths, proposing fixes, and explaining risk. They should not silently merge security-sensitive changes, alter IAM policies, rotate production credentials, or approve their own remediation.
Where agentic scanning works well
- Detecting insecure infrastructure-as-code changes before merge.
- Tracing whether a vulnerable package is reachable from production code.
- Identifying exposed secrets, overly broad IAM permissions, unsafe network access, and insecure model/tool bindings.
- Generating fix candidates for common policy violations.
- Prioritizing findings using call graphs, asset criticality, deployment targets, and runtime exposure.
Where caution is needed
- LLM-generated patches can introduce subtle behavior changes or compliance issues.
- Agents may overfit to local code patterns and miss architectural risks across services.
- Pre-submit checks can slow developers if latency is not tightly controlled.
- Security agents need access to code, dependency metadata, and cloud context, which makes their own permissions sensitive.
- Relying on one model provider or one scanning technique creates monoculture risk, a concern Google explicitly calls out in its recommendation for deliberate multi-model strategies [2].
The practical trade-off is layered control. Fast checks should block obvious high-risk changes. Deeper analysis should run asynchronously. Automated fixes should be proposed, tested, and reviewed. Runtime controls should assume something will still escape CI.
How We Would Implement It
1. Build a code-to-cloud security graph
Start by connecting repositories, CI/CD pipelines, artifact registries, container images, infrastructure-as-code, cloud accounts, identity policies, runtime services, model endpoints, vector databases, and data stores. The goal is a living graph that answers: what changed, where will it run, what can it access, and who can invoke it. This aligns with Google’s recommendation to unify context for machine-speed operations [2].
2. Add fast pre-submit scanning
Every pull request should run lightweight checks that complete quickly enough to preserve developer flow. These should include secret detection, dependency risk, infrastructure policy checks, model/tool permission checks, prompt and configuration linting, and reachable-code analysis where feasible. Findings should be tied to specific files, lines, resources, and deployment environments.
3. Use agentic triage for context, not blind blocking
An agentic triage layer should inspect ASTs, call graphs, dependency paths, IaC plans, and cloud metadata to reduce false positives. Google’s reported approach shows why this matters: localized threat models and specialized triage agents can materially improve precision and keep pre-submit feedback under a minute [1].
4. Run deeper post-submit and nightly scans
Not every risk can be evaluated in a pull request. Deeper integration scans should test cross-service paths, deployed IAM permissions, artifact provenance, container vulnerabilities, exposed endpoints, network paths, and model/tool execution chains. Google’s two-layer model of lightweight pre-submit scans plus nightly post-submit integration scans is the right pattern for scale [1].
5. Generate fixes as pull requests
Automated remediation should produce small, reviewable patches with evidence: the finding, exploit path, affected assets, test results, and policy reference. Human review remains mandatory for production-impacting changes. This mirrors Google’s use of an automated bug-fix agent that submits fixes for human approval [1].
6. Secure the AI platform itself
- Use short-lived credentials and workload identity instead of long-lived API keys.
- Separate development, staging, and production model credentials.
- Apply least privilege to agents, model tools, vector databases, and CI runners.
- Restrict egress from build and model-serving environments.
- Monitor GPU allocation, model downloads, unusual token usage, and abnormal agent tool calls.
- Maintain software bills of materials for application code, model-serving images, and ML dependencies.
- Use policy-as-code for cloud resources, model endpoint exposure, data access, and tool permissions.
7. Adopt multi-layer model and provider controls
For critical workflows, use multiple detection methods: deterministic rules, static analysis, dependency reachability, LLM-based reasoning, runtime telemetry, and human review. A multi-model strategy can also reduce dependence on a single model family and limit correlated failures, consistent with Google’s guidance to avoid AI monocultures [2].
Risks, Costs and Security
Costs
- Compute cost: Large-scale repository analysis, call-graph generation, container scanning, and LLM-based triage consume CPU, storage, and model inference budget.
- Developer time: Poorly tuned controls create friction. The business case depends on reducing false positives and producing actionable fixes.
- Platform integration: The highest-value results require connecting code, CI/CD, cloud assets, identity, runtime telemetry, and data systems. That integration work is non-trivial.
- Ongoing maintenance: Policies, dependency rules, model prompts, and remediation templates must evolve as architectures and threats change.
Security risks
- Agent over-permissioning: Security agents often need broad read access. Write permissions should be narrowly scoped and heavily audited.
- Prompt injection and tool abuse: Agents that inspect untrusted code, issues, logs, or documentation can be manipulated. Tool execution must be sandboxed.
- Supply-chain compromise: AI development stacks depend on fast-moving packages and model tooling. Google reports large-scale open-source supply-chain contamination and hijacked AI toolkits [2].
- Credential exposure: Exposed tokens can enable unauthorized AI infrastructure usage, including GPU theft and model access abuse [2].
- False negatives: High precision does not mean complete coverage. Runtime monitoring, red teaming, and incident response remain necessary.
Practical controls
- Keep pre-submit gates fast and focused on high-confidence risks.
- Route medium-confidence findings to asynchronous triage rather than blocking all merges.
- Require human approval for generated fixes and production policy changes.
- Log every agent decision, tool call, prompt, input artifact, and generated patch.
- Use sandboxed execution for code analysis and proof generation.
- Continuously reconcile cloud runtime state against intended infrastructure definitions.
- Monitor for anomalous AI resource creation, model access, token usage, and data movement.
The production lesson is clear: enterprise AI platforms need security built into the engineering path, not bolted on after deployment. Agentic systems can make scanning and remediation faster, but only when constrained by strong architecture: contextual analysis, layered controls, least privilege, human review, and continuous code-to-cloud visibility.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice, or Estimate My Infrastructure.
