[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3buv9566zsoo2":3},{"code":4,"message":5,"data":6,"timestamp":29},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":25,"homepage":26,"updated_at":27,"history":28},"agentshield-dev\u002Fagentshield",22,"Agentshield is open source defense for Kubernetes and AWS. It learns how your workloads really talk, flags lateral movement with evidence, and proposes fixes you approve.","Go",50,2,16,3,[],"Correlates Kubernetes and AWS network policy sources to flag newly opened lateral-movement paths, with evidence and approved fixes.","A pre-1.0 tool for platform and security engineers who want change-driven evidence about who can reach what in a Kubernetes cluster. Try it if you run Istio ambient, Cilium, or agentgateway and can accept an unauthenticated local UI, no published accuracy results, and a single-process deployment.\n\n## The problem\n\nAnswering \"who can reach what\" today means reading NetworkPolicies, CiliumNetworkPolicies, Istio AuthorizationPolicies and PeerAuthentications, Gateway API routes, and AWS Security Groups side by side, then redoing the work after every change. The user's goal is to know when an ordinary-looking configuration change opens a path that was not there before, and to have evidence for that claim. agentshield changes the step: plugins watch these sources, publish their output into one PostgreSQL graph with an ordered change feed, and detectors turn graph changes into signals. The result is a browsable graph plus findings, rather than a manual diff of several policy languages.\n\n## What's different\n\nThe mechanism is a claim of joining discovery and change: source plugins (`kubernetes`, `aws`) watch provider APIs, semantic plugins (`istio`, `cilium`, `agentgateway`) read the same watches and add meaning, and each plugin publishes its full current output as a contribution to PostgreSQL. Telemetry such as OTLP logs and VPC Flow Logs lands in a raw sink (JSONL or ClickHouse) before per-minute summaries join the graph. Detection itself never calls a model; only optional agentic investigation and deployment-rule authoring do, and only when explicitly enabled. A model investigator works through read-only graph tools, and per the README only answers citing real graph evidence become findings. A finding can propose a fix, applied only after a person prepares and approves it.\n\nThe trade-off is concentration: one process per database, no high availability, and a schema and flag surface the project says will break before 1.0. The README also states there are no published accuracy results; the evidence offered is an evaluation suite of six campaigns run against a disposable kind cluster with Cilium, Istio ambient, and agentgateway, in three attack\u002Fbenign pairs.\n\n## Who should try it\n\nA good fit is a platform or security engineer already running Istio ambient, Cilium, or agentgateway, optionally on AWS, who wants a local graph of reachability and change signals before investing in wider rollout. A poor fit is anyone who needs an authenticated, highly available production service now: the HTTP API and UI have no authentication and the server binds to 127.0.0.1:8088 by default, the README directs readers to the security model before changing that, and only one process per database is supported. Contributors wanting to add providers, detectors, or evaluation scenarios are a documented audience. If you only want to view the UI, the interactive playground runs against a fake in-browser backend with `make` plus Node.js and pnpm, no Go, database, cluster, or model, so evaluation does not require a cluster.\n\n## Requirements and limitations\n\nThe quickstart needs Go 1.27+, Docker with Compose v2 for PostgreSQL 16 and kind, kind and kubectl or any Kubernetes 1.30+ cluster in the current context, and Node.js plus pnpm 11 to build the UI (skip with `UI=0`). Discovery only reads, but `make run` enables live remediation with your kubectl credentials, so the README advises a read-only context if you only want to look. No container image is published yet: binaries come from tagged GitHub releases, while a container image must be built from the `Dockerfile` and deployed with the Helm chart. Optional agentic investigation requires an OpenAI Responses-compatible endpoint and its own flags. Ongoing upkeep is the real cost: expect breaking changes to APIs, schema, and flags, and plan around a single-instance database.\n\n## HotRepo's take\n\nHotRepo first tracked the repository at 3 days old and recorded 50 total stars at #22 on the NEW-REPOSITORY board on 2026-10-25, not an overall or daily Trending rank; with only two recorded dates and insufficient comparable daily history, persistence cannot be judged. For a pre-1.0 project, the point to verify before committing is the [security model](https:\u002F\u002Fagent-shield.dev\u002Fdocs\u002Foperations\u002Fsecurity\u002F) behind the default localhost binding.",{"slug":19,"name":20},"security","Security & Privacy",[22,23,24,19],"agents","artificial-intelligence","defense","Apache-2.0","https:\u002F\u002Fagent-shield.dev","2026-10-25T03:17:39Z",[],1792909354]