AI security infrastructure

Admission control layer for self-hosted LLM inference serving coding agents

AI Engineer — Your Self-Hosted LLM Needs to Say No - Harshul Jain & Parv Khatri, Audible & SAP

Add an ingress decision layer in front of a self-hosted vLLM or SGLang engine that admits, defers or rejects each request before it takes any GPU memory. Coding agents fan out into dozens of LLM calls with retries in seconds, and every layer of a standard stack (agent, gateway, router, engine) only notices overload after saying yes, so capacity is consumed by requests that then miss latency targets. The layer reads both the request (input length, tenant, agent session, deadline) and live engine state (KV cache usage, queue age, cache hits, replica load) — a view no existing layer has.

Problem: Overload buries the requests you needed first: a burst far above capacity makes the engine wait, swap or error, missing SLOs and wasting memory, because every admission decision today happens only once the request is already on the GPU

For: Teams hosting their own LLM on their own GPUs for privacy or cost reasons whose main traffic is coding agents or other high-fanout automated callers

Examples

• OpenAI's November 8, 2023 outage: routing servers ran out of memory under heavy traffic and failed health checks; the fix was cutting incoming traffic and ramping it back up slowly — graceful load shedding

Enterprise agentic last-mile identity and access control layer

IBM Technology — Why AI Agents Break Zero Trust at the Last Mile

A security layer that bridges AI agents with fragmented legacy enterprise systems while preserving the user's identity, intent, context, and delegation.

Problem: Legacy systems commonly authenticate connecting applications with API keys or shared credentials rather than the user initiating the request. This loses identity, intent, context, and delegation, breaks zero-trust controls, enables agents to chain tools, and exposes backend systems to rogue agents.

For: Companies deploying AI agents that must access legacy backend processes and data systems.

Identity-based security infrastructure for multi-agent AI systems

IBM Technology — Kagenti’s Approach to Multi-Agent Security for AI Agents

Deploy an open-source security layer around multi-agent systems so authorization decisions use each agent's cryptographic identity and the full delegation chain, rather than relying on bearer tokens or a statically defined request path.

Problem: A confused deputy can receive a valid credential through an agent chain and use it to access data or tools it was never authorized to reach, potentially leaving only normal-looking authorized activity in the audit trail.

For: Organizations running multi-agent AI systems in production, including systems that process patient records, financial histories, internal communications, or other protected information.

Examples

• A hospital patient-billing system: Agent A orchestrates agents B, C, and D with a bearer token for patient data; Agent D receives the token while verifying insurance, and the delegation-chain policy blocks Agent D from patient records because it is not authorized for that resource.

Governed identity and policy control plane for AI agent actions

AI Engineer — A Valid Key Let an AI Agent Delete Production - Sagar Batchu, Speakeasy

A control layer that sits in the critical path between autonomous agents and the external systems they touch. Every agent action is resolved to a named identity, evaluated in real time against policy, capped so it never exceeds the issuing credential or the accountable owner's rights, and recorded in a signed audit log before execution. Built on the principle that valid credentials are not valid intent.

Problem: Agents act with borrowed user credentials and no identity, policy, approval or record between their judgment and an API — so a single wrong guess can delete production with valid keys, and no one can answer for it in an audit.

For: Companies in regulated industries running AI agents where auditors will ask who acted, who allowed it, and to see the record of what happened.

Examples

• The April incident where a founder's coding agent, asked to fix a staging credential issue, found a full-access infrastructure token in an unrelated file, deleted what it thought was a staging volume, and destroyed production and its backup in about 10 seconds with no exploit, jailbreak or malicious actor.

A guardrail tool that enforces strict test-driven development and other engineering rules for AI coding agents

Modern Software Engineering — The Most Important AI Coding Advice You Haven't Heard Yet

Use an automated validation layer to keep coding agents in a red-green-refactor cycle, prevent over-implementation, stop them from disabling lint rules, and require checks before changes are committed.

Problem: AI coding agents may skip TDD steps, over-implement solutions, disable lint rules, commit before running required checks, or write tests that do not provide sufficient confidence. Manual supervision is tedious and can allow bugs, unexpected behavior, undocumented assumptions, and unnecessary complexity.

For: Software developers and teams using AI coding agents who need confidence in agent-written code and want to supervise multiple agents without manually policing every step.

Examples

• RPG combat kata: the agent wrote a test that expected a magical sword's health to become four after use; Probity blocked an unnecessary use method that was not referenced and required a simpler implementation.

Privacy-first document preprocessing layer for AI coding agents

AI Engineer — Turning My Obsidian Vault Into a Local AI Engineer — Filip Makraduli, Superlinked

Instead of feeding raw sensitive files (scans, NDAs, invoices) into a coding agent like Claude Code and paying heavy token costs, sensitive document work — OCR, entity extraction, summarization, redaction — is offloaded to a self-hosted inference cluster exposed to the agent as an MCP server. The agent only receives a small, redacted Markdown artifact, cutting token spend, improving context quality, and keeping PII inside your own VPC.

Problem: Sending scanned or image-heavy documents directly to a large model is expensive in tokens, fills the context window with raw data, and leaks private or regulated information to third-party APIs. Open-source models are also often adapted poorly to niche tasks without fine-tuning.

For: Individuals and institutions with sensitive documents in an Obsidian vault (or similar) who use agents like Claude Code but cannot expose their files to external APIs.

Examples

• A scanned NDA with phone number and social security number is OCR'd and redacted into a masked Markdown document; the agent sees only masked entities (email, person) — 10 spans redacted in the demo.

Agentic fuzz-testing of sandbox platforms: point a coding agent at your own hosted sandbox environment and let it try to break it

AI Engineer — 1,000 Agent Tasks in a Sandbox: What Breaks When LLMs Run Code — Kevin Orellana, AWS

A platform engineer simulates real customers by wrapping the platform in an MCP server, releasing a coding agent against it, and having the agent generate and execute 1,000 test workflows across 10 domains. Results go into a SQLite database (not markdown files) so multiple sub-agents can run concurrently and failures can be queried. Failures are then classified into interface-layer bugs (issues in the MCP/encoding layer) versus sandbox-layer limits (memory, file permissions, persistence, seccomp, eBPF), because sandbox constraints decide whether an agent can finish its task at all.

Problem: Agent workloads are arbitrary and varied, so their demands on a sandbox environment diverge greatly from a classic long-running REST API service; sharp edges in sandbox primitives (filesystem permissions, mounted filesystems, persistence vs ephemerality, process spawning, memory) surface only when agents actually run diverse workflows, and are innocuous to human-written tests.

For: Engineering teams building or hosting agent platforms and sandboxed execution environments (code interpreters, cloud browsers) for agent workloads.

Examples

• The author's own run against Amazon Bedrock AgentCore: image uploaded and downloaded came back different due to incorrect encoding at the MCP layer; a null byte derailed tests; files written to a sandbox directory were not retrievable.

Slop Stop AI defense against automated sales outreach

My First Million — 9 drunk ideas that sound stupid (but are secretly genius)

An AI gatekeeper that responds to mass AI-generated outreach, asks the sender to do research and provide detailed follow-ups, schedules calls and requests contract revisions, consuming the spammer's time and resources instead of the recipient's.

Problem: AI makes it inexpensive to scrape contact details and send mass personalized-looking outreach, creating an increasing volume of sales spam that recipients must filter manually.

For: Business owners and professionals being overwhelmed by automated email, text and phone outreach from AI sales-development systems.

Examples

• AI sales development representatives: described as systems that scrape email addresses and contact people through email, text and calls while appearing to come from real people.

Shared AI team brain with cited, revisable business knowledge

ManuAGI - AutoGPT Tutorials — Top AI Agent Projects : Fluree AI, Pushary, Notte, OpenCode Superapp & Pulse

Connect company data sources into shared AI threads and a permissioned knowledge base that improves through corrections made during everyday work.

Problem: Teams repeatedly maintain context and correct AI answers because business knowledge is scattered and changes over time.

For: Teams across data, support, and go-to-market

Ephemeral least-privilege identity management for AI agents

IBM Technology — Can you social engineer an AI? Plus: AI worms and the nonhuman identity problem

Build identity and access-management infrastructure that provisions narrowly scoped identities and permissions for AI agents only when needed, limits them to the required action and time period, monitors their behavior, and removes their identities afterward.

Problem: Non-human identities can remain active indefinitely, escape regular monitoring, accumulate excessive privileges, and be abused without anyone noticing. Agents running under a primary or root user account can cause significant damage when they make mistakes.

For: Organizations operating AI agents, service accounts, APIs, or other non-human identities.

Examples

• OpenClaw was described as allowing anyone to run an agentic framework on a laptop; the panel warned that such agents may run under the main or superuser account and could make a large mess if they make a mistake.

Enterprise agent-security guardrail platform (cloud dev environment + model proxy + agent firewall)

AI Engineer — The Lethal Trifecta Is Already on Your Laptops — Michael Patterson, Coder

Coding agents running on developer laptops hit Simon Willison's lethal trifecta: access to private data, exposure to untrusted content, and external communication. Any two is unacceptable in a secure enterprise; all three means an incident is a matter of 'when', not 'if'. The proposed business is an architecture that gives agents a secure home: run them in isolated cloud development environments instead of laptops, route their LLM traffic through a proxy that logs everything and strips sensitive data, and sit a firewall at the process level that denies commands and domains that were not pre-approved.

Problem: Agents on laptops can exfiltrate credentials, company IP and databases, download malicious content, and can be hijacked by prompt injection or context poisoning hidden in error messages, support tickets, CI/CD logs and documentation. Enterprises refuse to authorize agents without guardrails, which pushes developers into shadow AI on personal subscriptions — unauthorized agent usage the company cannot see, or 'ninja AI' at scale where many agents break things before anyone notices.

For: Companies rolling out coding agents (Claude Code, Codex, OpenClaw) at scale — specifically CISOs, platform teams, DevOps and security engineering who must approve and operate them.

Examples

• A developer who posted on Twitter that agentic coding changed his life, then two days later that an agent destroyed his product and deleted his production database

AI agent hardening service for existing Kubernetes platforms

AI Engineer — Build a Platform and Watch It Burn — Michael Forrester, Accenture & Whitney Lee, Datadog

A consulting/service offering that adds layered defenses around AI agents already running in a company's cluster: Kubernetes network policy (L4/L7), Kyverno admission rules restricting image sources and deployment requirements, agent identity via Spiffe/Spire, runtime security, and an LLM Guard proxy in front of the agent providing input and output sanitization plus MCP/tool checking. The pitch: excessive agency is an infrastructure and process problem, not an AI problem — don't let agents have direct access, stick to known flows, and extend the CI/CD and SDLC controls you already have.

Problem: Teams give agents oversized scopes without knowing elevated credentials sit in the environment; relying on the model to refuse is unreliable since refusals are probabilistic and attackers can often bypass them within 20–30 prompts.

For: Enterprises running or about to run AI agents inside Kubernetes — the three use cases named: AI-assisted software development, AI added to an existing application, and AI-managed systems (the riskiest).

Examples

• The second demo cluster where the same prompts that succeeded on the exposed cluster were blocked: image deployment stopped by Kyverno, filesystem snooping intended to be stopped by runtime tooling (incompletely in the live run).

Centralized Agent Authentication and Authorization Platform

AI Engineer — Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard

A secure infrastructure layer that governs all interactions between autonomous agents and downstream services (APIs, databases), ensuring that all agent actions are securely brokered, attributed to a specific user, and governed by strict policies.

Problem: The inherent security risks of current agent credential practices, which include using insecure personal tokens, static over-privileged service accounts, and the inability to attribute actions or enforce fine-grained access control at scale.

For: Organizations deploying complex autonomous agent systems across diverse and often legacy enterprise infrastructure.

Local coding-agent observability and policy monitoring

Github Awesome — GitHub Trending Weekly #42: nimbus, xy, persona, drawesome, letsseal, camelAI, OpenSlides, numbat

Numbat monitors coding agents on an endpoint without requiring a cloud service, unifying supported hooks, OTLP logs, and saved session artifacts into one event format with local CEL rules for alerts and forensic timelines.

Problem: Provides local visibility into coding-agent activity, alerts, and historical investigations without sending monitoring to a cloud service.

Examples

• Numbat: monitors coding agents locally and produces live alerts or forensic timelines.

Internal agent registration portal that scaffolds a governed agent with all supporting frameworks

AI Engineer — Paving the Road to Production: Governed Enterprise AI Agents — Harish Gaggar, Credit Karma

Instead of letting developers hand-roll agents, an internal portal registers the agent (use case, ID, framework, language, skills, prompts) and generates a repository that already contains the agent framework plus memory, tracking/eval, context-optimizer and PII-blocking frameworks, so every agent in the company ships with the same production foundations.

Problem: Agents fail in production because foundations are missing: no authentication gateway, no tool governance, no tracking and evaluation, no memory management, no PII interception, no token control.

For: Engineering organizations deploying many AI agents in production

Examples

• Intuit Credit Karma runs this paved path internally so every agent gets a consistent route through access control, observability, durable state and accountable action.

AI-powered defensive vulnerability discovery and remediation

IBM Technology — Can you social engineer an AI? Plus: AI worms and the nonhuman identity problem

Use a self-propagating or distributed AI methodology defensively: identify vulnerabilities across devices, explain how to fix them, and potentially patch the vulnerabilities instead of exploiting them.

Problem: Traditional security teams may struggle to find vulnerabilities across changing environments quickly enough, while attackers can use similar AI techniques to discover and exploit them.

For: Organizations that need to discover and remediate vulnerabilities across their environments.

Examples

• University of Toronto researchers' self-replicating agent used an open-source LLM, spread from device to device, ran a local model, and selected different vulnerabilities and exploits for each device.

An agent governance platform for enterprises running many production agents

AI Engineer — AI Engineer NYC Livestream | Bridgewater, Anthropic, Two Sigma, Arize, Coatue, Nous, Gen. Intuition

A composable control layer that lets a company give AI agents real autonomy in regulated environments without locking everything down: an agent registry that makes every agent visible, risk scoring so reviews scale with danger, purpose-declared tool entitlements, shared evals, and a runtime governed by classifiers instead of blanket human approval.

Problem: Non-deterministic agents are given autonomy over consequential systems (like the bank software that accidentally sent $900 million instead of $8 million in the Revlon/Citi incident). Blanket lockdown kills innovation, wide-open access is unsuitable for regulated firms, and policy documents in prompts aren't enforceable at runtime; meanwhile human-approves-every-action collapses into review fatigue.

For: Highly regulated enterprises (banks, hedge funds, financial infrastructure) whose teams are spawning agents everywhere with no one able to answer who owns an agent, what it can touch, or what it should and shouldn't do.

Examples

• Two Sigma's internal five-control agent governance architecture: agent registry, risk-based review, purpose-declared tool entitlements, shared evals, runtime classification.

Build an isolation-native AI research system for corporate analysis

AI Engineer — Can Your AI Analyst Keep a Secret? - Aaron Linsky, Bridgewater & Nikhil Benesch, turbopuffer

Develop an AI analyst that can process and ground its research in massive private document repositories while strictly adhering to granular access permissions.

Problem: Standard vector search fails when applied to documents with complex permissions, either providing poor recall by discarding non-matching documents during post-filtering or suffering from excessive latency by scanning unauthorized documents during pre-filtering.

For: Organizations (e.g., financial institutions) that need AI agents to process 100 million permissioned private documents (internal and external research).

Examples

• Bridgewater: Uses the system to power its AI analyst, allowing it to search 100 million documents while respecting complex internal and external document permissions (00:21, 03:43).

Git-based control plane for enterprise AI agents

ManuAGI - AutoGPT Tutorials — Top AI Agent Projects : Omniwork, Argos, Fin, Firecrawl & BrowserOS neo

Enterprises define agents as versioned files in their own repositories, specifying context, skills, tools, permissions, and identity so runtimes can read only what each agent is allowed to access.

Problem: Vendor-specific agent harnesses scatter context, tools, and lessons and make switching costly.

For: Enterprise organizations managing multiple AI agents.

Local browser that AI agents operate through users' logged-in accounts

ManuAGI - AutoGPT Tutorials — Top AI Agent Projects : Omniwork, Argos, Fin, Firecrawl & BrowserOS neo

Users import Chrome logins, connect agents over MCP, and delegate web tasks to isolated tabs while keeping the main browser, credentials, screenshots, and session replays local.

Problem: Chat assistants can describe actions but cannot reliably open tabs, sign in, and click through real websites.

For: People who run AI agents on the web.

AI-assisted Kubernetes remediation control plane

ManuAGI - AutoGPT Tutorials — Top Open-Source GitHub Projects : LobeHub, clawk, Jolt Physics, Clodex, mindwalk & Persome #276

A source-available infrastructure platform that connects alerts, evidence, topology, human approval, controlled remediation, recovery verification, and learning into an auditable loop.

Problem: Diagnosing and remediating infrastructure incidents while keeping execution governed, auditable, and verified against the original symptom.

For: Infrastructure and platform teams operating Kubernetes and cloud systems.

Centralized MCP gateway with internally built, security-reviewed MCP servers

AI Engineer — Paving the Road to Production: Governed Enterprise AI Agents — Harish Gaggar, Credit Karma

Build your own MCP gateway so every agent or coding-assistant tool call is authenticated centrally before being routed to MCP servers, and build custom MCP servers (e.g. with FastMCP) whose tools are reviewed by the internal security team — with no direct access to any endpoint.

Problem: Agents lack a gateway for authenticated communication, and unreviewed MCP servers can expose tools and fields that should never reach the LLM.

For: Teams running agents, especially in air-gapped enterprise environments

Examples

• Credit Karma's internal gateway authenticates any coding assistant tool or agent and routes it via MCP servers to endpoints such as Artifactory.

Runtime intent-based authorization layer for AI agents

AI Engineer — An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth

A service that authorizes each agent tool call at runtime using the mission and intent as context, replacing coarse-grained standing credentials like API keys and coarse OAuth scopes. The agent holds no broad access; each action is evaluated within the context of what the user or business is trying to accomplish, drawing on practices banks already use for authorizing transactions.

Problem: Current systems were designed for humans making deterministic decisions; coarse scopes (e.g. an API-wide Salesforce scope) let a reasoning agent retry repeatedly and do damage it was never supposed to be able to do.

For: Enterprises deploying AI agents, especially regulated industries like financial services that put security first.

Examples

• Salesforce's single coarse 'API' OAuth scope as the counter-example that motivates finer-grained agent authorization.

KV-cache-based security monitoring for AI agent inference stacks

AI Engineer — Your KV Cache Can Spot Attacks on Your AI Agents - Ari Azarafrooz, Intrinsec AI

Use the KV cache that inference engines already compute as a security signal: learn a baseline of how KV pages look for normal traffic, flag anomalous pages, then classify and explain them. This complements edge guardrails (judge models, per-failure classifiers) because anything that slips past input/output filters still becomes computation, and the data stays in place, which suits privacy-sensitive deployments.

Problem: Guarding only inputs and outputs with judge models or one classifier per failure mode leaves blind spots — e.g. a hidden spoken instruction in a voicemail where there is no text to filter. The KV cache records every computation regardless of modality, so anomalies can be caught there for free.

For: Teams that build AI agents and run (or plan to run) their own inference stack and treat security as a foundational design decision.

Examples

• Voice agent on Gemini 4 04B: baseline of 72 ordinary clips in four voices, 16-token pages; hidden spoken instructions detected without any text to filter.

LangGraph agent workflow with policy classification and human-in-the-loop approval

AI Engineer — Paving the Road to Production: Governed Enterprise AI Agents — Harish Gaggar, Credit Karma

A virtualization and management layer for AI agents (a 'VMware for agents')

a16z — Former Intel CEO: Why This is the Best Time to Build Hardware

Rebuild the entire virtualization and management stack — security profiles, performance management, policies, migration — but designed so the primary 'user' of the infrastructure is an AI agent rather than a human. Every fundamental element of the VM abstraction (security, performance, abstraction, migration — 'vMotion for agents') gets a new embodiment, while humans set the policies, constitutions and guard rails and view dashboards.

Problem: AI infrastructure today is designed for humans; agent swarms need someone to manage the agents, create security profiles around them, manage their performance, and enforce guard rails or constitutions — none of which the current virtualization stack provides.

For: Teams running agent swarms that need managed, secure, performant infrastructure; the infrastructure is built to be consumed by agents themselves, with humans setting policies and oversight.

Examples

• VMware — the analogy the idea is built on: it managed every aspect of the computing hierarchy (workload, network, storage) for humans, and the same management surfaces need recreating for agents.

Autonomous agent signup flows that bridge agents into existing human sign-up surfaces

AI Engineer — The Next Trillion Internet Users Still Don’t Have an Identity — Adi Singh, AgentMail

Companies building agent-facing services can let agents sign themselves up autonomously by provisioning them a real email inbox through an API mid-flow. The agent then completes the same verification flow designed for humans, receives an API key, and the inbox becomes a permanent contact point for billing alerts, suspensions, support and failure/recovery communications.

Problem: Agents get stuck at email verification because sign-up flows were scoped for humans and the agent has no email address of its own; without one it cannot verify, cannot receive billing/support notices, and there is no audit of what it signed up for or how to reach it later.

For: API and infrastructure companies (like phone carriers) who want agents to be able to self-onboard to their platform

Examples

• Telnyx agent signup: added an AgentMail inbox API call so agents can self-verify, get an API key, and stay reachable for billing and support; the agent inbox became Telnyx's focal point for low-balance alerts, suspensions, support and recovery notices.

PII/MNPI leak audit and suppression for LLM-as-judge pipelines

AI Engineer — Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait — Al Chen, Cisco

UI redaction hides sensitive data from human users, but LLM judge system prompts (e.g. an instruction to quote the agent's answer for human verification) can cause the judge's persisted reasoning to un-redact PII or MNPI. Audit judge traces for leaks, then persist scores always but persist reasoning only after a sensitivity check, or run a second judge on redacted input.

Problem: Side-channel leakage: the UI looks redacted, but LLM judge reasoning stored and displayed can contain un-redacted customer PII or material non-public information.

For: Banks and any AI platform vendors whose evaluation pipelines surface judge reasoning to internal users

Governed enterprise environment for building AI agents, apps, and automations

ManuAGI - AutoGPT Tutorials — Top AI Agent Projects : Omniwork, Argos, Fin, Firecrawl & BrowserOS neo

Organizations provide a self-service path for teams to build AI systems while security and IT retain visibility and control over what exists, who built it, and what it can access.

Problem: Uncontrolled internal AI development can expose keys, use personal accounts, and ship ungoverned applications.

For: Security, IT, and enterprise teams.

Examples

• Alert triage, IT deployments, finance requests, and hiring are named as supported workflow examples.

Gateway-level observability stack for agent tool calls

AI Engineer — Paving the Road to Production: Governed Enterprise AI Agents — Harish Gaggar, Credit Karma

Collect operational logs, traces and metrics on the MCP gateway so agents cannot be trusted without continuous monitoring, evaluation and feedback — logs answer questions like which calls returned 401s or why a token refresh failed, traces show which tool was slow or which call failed, and metrics expose P95 latencies and auth-rejection spikes.

Problem: Without visibility into failures, latency and access behavior on every tool call, agents cannot be trusted in production.

For: Platform teams operating agent infrastructure

PII interception layer that blocks and redacts secrets before models, memory or traces

AI Engineer — Paving the Road to Production: Governed Enterprise AI Agents — Harish Gaggar, Credit Karma

Supervising-agent service running policy separate from worker agents

AI Engineer — An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth

A separate supervising agent — one that does no work itself but decides what the worker agents may do — sold as an independent, pluggable component. A protocol boundary between supervisor and worker lets users swap either piece instead of the agent vendor deciding the guardrails.

Problem: Agents and their vendors currently decide their own guardrails; human-in-the-loop approval does not scale and causes consent fatigue, so control over what agents can do needs to live in a component the owner controls.

For: Individuals and organizations running many agents whose volume makes human approval of every action impossible.

Examples

• The web's federated-protocol precedent — OIDC, TLS — as the model for open agent-authorization rails versus walled-garden personal-agent protocol efforts.