Zero trust for AI agents
Default deny for non-human workloads, enforced outside the runtime.
Agents have no device posture and no human identity. Verify every connection, scope every destination, hold every unknown.
- bedrock-runtime.us-east-1.amazonaws.com
- sts.us-east-1.amazonaws.com
- api.internal.example
Zero trust was built for people and devices
Identity providers verify a person. Device posture verifies a laptop. An agent is a process with an API key that makes thousands of connections a minute to destinations a model chose. The controls that verify who and what do not answer where it may go.
No user to verify
The agent authenticates with a key. MFA and posture checks have nothing to evaluate.
Destinations decided at runtime
Least privilege on a static list does not cover a model that picks a new host per task.
Trust placed inside the runtime
An SDK or sidecar is part of the thing being attacked. The policy has to sit outside it.
Default deny by name, per role
One policy per role
The invoice agent policy resolves the ERP and the payment API. Nothing else answers. A research agent gets a different policy.
Deny by default, hold the unknown
Default Action Deny and Greywall Mode Enforce. New names wait for a human or expire by policy.
Log and forward every decision
Accept, block, threat and greywall, with the reason. The SIEM sees an agent doing something new before it finishes.
Zero trust controls for agents
Default deny
A policy with Default Action Deny resolves its allow list and approved categories and nothing else.
Identity per instance
A DoH virtual site per agent instance. Events carry the instance name; approvals apply to the role.
Hold on first sight
The Greywall holds any name the policy has not resolved before, for as long as the policy says.
Every environment
Kubernetes, Docker, AWS, GCP, Azure, VMs, CI runners and workstations. The resolver exists in all of them.
Continuous verification
Every lookup is a decision with a reason, not a session that was trusted once.
Automation
Create and approve through the API with scoped keys. Every change recorded and revertible.
What stays in the firewall
Securd governs destinations reached by name. A connection to an IP address the agent already holds is governed by the egress firewall, which stays. Restrict port 53 and 853 to the Securd resolvers, block the DoH provider category in the policy, and a bypass attempt becomes a firewall log line.
| Timestamp | Action | Site | Query Name | Source IP | Reason |
|---|---|---|---|---|---|
| 2026-09-15 14:02:11 | accept | research-agent | api.openai.com | 10.40.2.17 | allow list |
| 2026-09-15 14:02:11 | accept | research-agent | api.tavily.com | 10.40.2.17 | allow list |
| 2026-09-15 14:02:14 | greywall | research-agent | cdn-assets-sync.top | 10.40.2.17 | first seen, held 24h |
| 2026-09-15 14:02:14 | block | research-agent | dns.google | 10.40.2.17 | category: DoH provider |
| 2026-09-15 14:02:19 | threat | research-agent | update-check.pw | 10.40.2.17 | feed: c2-indicators |
| 2026-09-15 14:02:31 | accept | finance-agent | api.stripe.com | 10.40.3.8 | allow list |
Questions teams ask
Does Securd verify agent identity?
Securd identifies the requesting policy and site. Identity per instance is a virtual site address handled as a credential. It does not authenticate the model or the code.
Is this a service mesh replacement?
No. A mesh governs service-to-service traffic inside the cluster. Securd governs what the workload resolves on the way out, without a sidecar.
What about hardcoded IPs?
Out of scope for a resolver, in scope for the egress firewall. The deployment standard shows the two rules that close it.
Put one production agent on default deny
Learn for a week, enforce with a long hold, and watch the queue stay empty.