Most of the agent security conversation so far has been about your agents and how to secure them. Agent identity, guardrails, sandboxes, gateways, a human in the loop for approval. We've spent a lot of time there with agentgateway and kagent, and those controls improve security for agents, but they work only when the agent runs through your control points. An attacker's agent doesn't. Neither does a partner's agent that wandered outside its boundary, or your own agent the moment a sandbox or credential scope fails. Whichever agent it is, what it reaches is your data, APIs, and services you were already running, so that's where the protection has to live.
And the gaps these agents find usually aren't new. Breach investigations like the Snowflake customer intrusions keep turning up stolen credentials that still work, permissions nobody trimmed, and workloads that can reach systems they never needed. We know the practices (least privilege, segmentation, zero trust), but they drift and that’s reality, e.g. unclear ownership, legacy systems, exceptions added to keep something running. A human attacker might never stumble onto that one forgotten path, but an agent that keeps trying paths and re-plans after every block probably will.
Today we're open sourcing agentshield, a layer of protection around your existing infrastructure for the agents you don't control and data and API that should already be secured. It builds an attack-path graph from the systems you already run, enforces rules against it in real time, uses a model to reason continuously over what changes, and proposes fixes that a person, or an agent operating under your policy, can apply.
What can agentshield do?
- Plugins at every layer: read the platform, network, identity, cloud, and runtime sensors you already run, e.g. Kubernetes, Istio, Cilium, agentgateway, AWS, and Falco to start, with eBPF sensors like Tetragon next. Your existing tools keep enforcing; agentshield connects what they know, and nothing depends on what an agent reports about itself.
- One attack-path graph: workloads, identities, policies, exposure, and observed traffic become related facts, each traceable to the observation behind it.
- Real-time rules, continuous reasoning: rules run against every change with no model in the path, while a model samples the graph at a rate you set to find new attack paths as they develop.
- Findings built for action: affected systems, evidence, whether the threat is still active, and a proposed fix, routed to on-call and ticketing.
- Remediation by a human or by an agent: plugins declare the actions they can take, the model proposes from that menu, and you set the blast-radius threshold for what runs without a person approving it.
How does agentshield work?
Plugins turn provider observations into resources and relationships with stable identities, so a Falco shell alert, the Deployment that owns the Pod, its service account, and the NetworkPolicy or Istio AuthorizationPolicy that selects it all point at the same Pod. That's the context a single alert never has: what the Pod talks to, what identity it runs as, and which policies are supposed to govern it. Every assertion records the plugin, source, rule, and evidence behind it, so you can follow any edge back to what produced it. High-volume traffic and runtime events stay in a telemetry pipeline (JSONL/ClickHouse) and only bounded per-minute rollups join the graph, so the model reasons over the graph rather than raw telemetry as the environment grows. See the pipeline overview for the full path.
Detectors watch the graph for changes like an established workload reaching a new destination, losing a governing policy, becoming publicly exposed, or starting to use a new identity. You can add your own rules in CEL, scoped to a specific workload if you want. For example, this one matches new connections to public destinations with no known role:
A matching rule becomes a finding with no model call, so detection never waits on a model. A model can also draft rules from a new Deployment's service account and observed behavior, and those run in shadow mode (matches are recorded, nothing fires) until someone who owns the application approves them. So where does the model come in for everything else? Novel changes rated medium risk or higher go to an investigator, through a sampled and budgeted queue, and the investigator pulls more context through read-only MCP tools. Its answer has to cite evidence that a validator checks before the finding is promoted, and the finding is invalidated if the resources it's about change underneath it.
When a finding proposes a fix (e.g. ingress isolation or STRICT mTLS), the operator picks from the actions the plugins advertise for that target. agentshield builds a concrete plan, has the provider check every write (for Kubernetes, with an admission dry-run), and applies nothing until the operator approves that exact plan. The provider then re-reads the prepared state, applies the change, and re-reads the configuration to verify it landed. NetworkPolicy, CiliumNetworkPolicy, and Istio PeerAuthentication are the first actions, and the remediation workflow has the details.
See agentshield in action
Getting started
The quickest way to try it is the playground, which runs the real UI against an in-browser fake backend (you need make, Node.js 22.12+, and pnpm 11):
git clone https://github.com/agentshield-dev/agentshield.git
cd agentshield
make demo
Open http://127.0.0.1:5173, pick a scenario, trigger it, and follow the finding through its evidence to an approved fix. To point it at a real cluster, the getting-started guide covers PostgreSQL, Kubernetes, AWS, telemetry, and model configuration. agentshield is early (pre-1.0) and its API and UI are unauthenticated and bind to loopback by default, so read the security model before running it anywhere but a test environment.
Get involved
Agentshield is Apache 2.0. Keep putting identity and guardrails on your own agents, but assume some agent you don't control is already probing your infrastructure, and start finding the paths it would take. If there's a source your team needs that we don't cover yet (another cloud, another runtime sensor, your IdP, etc.), we want to hear about it.
- Explore the code and open issues on GitHub.
- Read the documentation and the plugin contributor guide.
- Join the discussion on Discord.
%20(1).png)
%20a%20Bad%20Idea.png)
