AI Security Does Not Stop at the Prompt: What Kubernetes and GPU Teams Need to Verify

For teams running AI agents on shared GPU infrastructure, a security review can look beyond prompts, model access, and credentials to the workload’s environment and the GPU software stack. Andrew Martin’s InfoQ presentation, “Exploding GPUs,” discusses why AI security is tied to Kubernetes security and names risks and defenses that can serve as starting points for that review ¹.

What the talk says about AI security and Kubernetes — and what its summary leaves open

InfoQ’s summary of Andrew Martin’s presentation, published by InfoQ AI, ML & Data Engineering on October 16, 2026, says AI security is fundamentally tied to Kubernetes security for cloud-native AI workloads in production ¹. It names three risk areas — non-deterministic agent behavior, GPU supply-chain vulnerabilities, and shared-compute risks — and two defense strategies: prompt firewalling and agentic identity ¹.

The summary does not specify incident examples, exploit chains, Kubernetes configurations, or step-by-step remediation. Treat the categories below as prompts for investigation, not as evidence that a particular failure has occurred or that any control is already in place ¹.

Beyond prompts and credentials: AI agent security risks

As a review approach, ask not only whether an agent produced an unexpected response, but also what its workload could access or affect. That directs attention to permissions, resources, and infrastructure as well as prompts and credentials. For a related look at how teams make agent actions and dependencies accountable, see IBM's agent operations direction.

A risk label is not itself a control. The checks below are my proposed starting points; they are not controls specified in the InfoQ summary.

Risk named in the summary	Proposed review questions
Non-deterministic agent behavior 1	Which actions are permitted, which require approval, and how are actions logged?
GPU supply-chain vulnerabilities 1	Which GPU-related software and infrastructure does a workload depend on? Who supplies and patches it, and how are changes reviewed?
Shared-compute risks 1	What is shared, where are the isolation boundaries, and what evidence supports the isolation assumptions?

Reviewing shared GPU security for Kubernetes AI workloads

The InfoQ summary names shared-compute risk but does not identify a specific attack scenario or isolation failure ¹. Rather than assume which one applies, document the boundaries your architecture depends on. For each AI workload, consider asking:

• Does it share a node or GPU with other workloads?
• Can one workload discover or address another on the network?
• What permissions does a process need to access the accelerator?
• What happens to temporary data and workload state when a job ends?
• What separates workloads at the namespace, pod, node, device, memory, storage, and network layers?

A claim of workload isolation is more useful when it identifies what is shared, what is separated, which component enforces that separation, and what evidence supports the claim. If an assumption is undocumented or untested, record it as an open risk rather than treating it as verified.

Reviewing GPU supply chain security

The summary names GPU supply-chain vulnerabilities but does not identify specific components or failure modes ¹. A practical review can start by inventorying the GPU software and infrastructure each workload depends on, along with who owns those components.

Record the dependencies, their suppliers and update owners, how version changes are approved, and what would stop an unreviewed change from shipping. These are proposed review questions, not steps prescribed by the talk.

Keep this review separate from runtime isolation. Reviewing a supply chain does not, by itself, establish whether workloads are isolated from one another; an isolation review does not, by itself, establish whether dependencies have been vetted.

Scope check: The InfoQ summary does not attribute specific signing, scanning, attestation, or vendor tools to the talk. Do not present those as its recommendations ¹.

What prompt firewalling and agentic identity need to establish

The summary names prompt firewalling and agentic identity as defense strategies but does not specify their implementation ¹. Treat the terms as starting points for questions, not as proof that a working control exists.

For this review, one possible working interpretation is that prompt firewalling concerns filtering or constraining instructions reaching a model or agent, while agentic identity concerns associating an agent’s actions with an identity and defined permissions. This is an analytical framing, not a technical definition supplied by the summary. Teams in regulated sectors are working through a similar problem; see how financial firms are defining boundaries for AI agents.

For each proposed control, ask:

• What input or action does it cover?
• Where is the decision enforced — client, gateway, or model provider?
• Which actions require explicit authorization?
• What happens when the control fails open, fails closed, or cannot decide?
• Who owns it, and what audit trail shows how it behaved?

A named strategy needs implementation details and evidence before it can be assessed as an operational control.

What to do next

As a practical approach, bring security, platform, and AI engineering into a joint review so teams can compare assumptions across workload and infrastructure boundaries.

1. List the AI workloads and where they run. Record placement and infrastructure dependencies for each.
2. Map access broadly. Include models, data, GPUs, nodes, and cluster APIs, not only prompts and credentials.
3. Identify shared resources and name an owner for each boundary.
4. Pair each named risk with an enforcement point and review evidence.
5. Keep an unknowns list. Do not treat an unspecified control as implemented.

Possible unknowns to track include which GPU vulnerabilities apply to your stack, which shared-compute scenarios exist in your cluster, how prompt firewalling and agentic identity would be implemented, and what Kubernetes configuration supports those choices. These details are not provided in the InfoQ summary ¹; they require investigation in your own environment.

What to measure

Instead of relying on broad assurances, track for each workload:

• Are its isolation assumptions documented?
• Do its GPU and runtime dependencies have a named owner?
• Are agent actions attributable to an identity and logged?
• Can review evidence be retrieved when needed?

This is a proposed coverage measure, not a benchmark. It can help show whether the review produced documented answers and evidence.

Bottom line: Treat prompt filtering and model-access controls as only part of an infrastructure review. Identify the workload and GPU boundaries your architecture depends on, name who enforces each one, and check that evidence exists.

Sources

¹ “Presentation: Exploding GPUs,” InfoQ AI, ML & Data Engineering, published October 16, 2026. https://www.infoq.com/presentations/ai-security-kubernetes-gpu-threats/