← Use Cases

Govern agents everywhere they run

One policy per role across cloud, Kubernetes, CI and workstations.

A single connection control plane for every agent, environment and cloud.

control.securd.com/gateway/acme/policies/research-agent
Policy: research-agent Published
Greywall Mode
Enforce
Hold Time
86400 s
Default Action
Deny Traffic
Allow list4 entries
  • api.openai.com
  • api.anthropic.com
  • api.tavily.com
  • api.smith.langchain.com
Block list2 entries
  • pastebin.com
  • transfer.sh
DoH providersMalwareC2ParkedSinkhole
The research agent policy, applied in Kubernetes, in CI and on a developer laptop.
The problem

The platform team owns the runtime, not the destinations

You provision the cluster, the runners and the model gateway. Product teams ship agents that decide where to connect. The security team asks for a list. The list changes with every deploy.

Every environment is different

Pods, Lambdas, runners and laptops each have their own way to set egress. The resolver is the one control they share.

Sidecars are a tax

A proxy per pod or a mesh change per cluster is a project. A resolver setting is a line in a manifest.

Approvals need an owner

A held destination needs a place to land: a queue, a webhook, a Slack action, not a Jira ticket to the platform team.

How it works

The platform pattern

Capabilities

Platform capabilities

Environment scope

Kubernetes namespaces, VPCs, CI runners and workstations each map to a site. Guides for every environment.

Runtime guides

Hermes Agent, OpenClaw, OpenHands, Claude Code, Codex CLI and Gemini CLI, with the vendor configuration files.

Management API

Create policies and sites, approve held names, publish and roll back. Thirteen scopes, keys that rotate.

Scope templates

Vendor-documented hostnames for model providers, tool hosts and MCP servers. Import before enforcing.

Webhooks

Six signed events. Route a held destination to the team that owns the agent.

Config as code

Every policy and list is API-addressable. Version the intent in your repo and apply it in the pipeline.

Level 0

One block in the manifest

A pod resolves through its policy with a dnsConfig. A NetworkPolicy pins DNS egress to the assigned resolvers. No sidecar, no mesh change.

pod.yaml
spec:
  dnsPolicy: "None"
  dnsConfig:
    nameservers: ["<primary resolver IP>", "<secondary resolver IP>"]
    options: [{ name: ndots, value: "1" }]
control.securd.com/gateway/acme/logs?dns_q.event=new
First-seen destinations Greywall Event: New Query
cdn-assets-sync.top
site research-agent 41 queries first seen 14:02:14 rank 0
Approve Block
api.exa.ai
site research-agent 12 queries first seen 13:58:02
Approve Block
pkg-mirror-cdn.top
site build-agent 3 queries first seen 13:41:50 rank 0
Approve Block
hooks.slack.com
site support-agent 88 queries first seen 09:10:33
Approve Block
Held destinations by agent, ready for the owning team to approve.

Questions teams ask

Does this work with our model gateway?

Yes. Approve the gateway hostname on each agent policy and give the gateway host its own policy for the providers it fronts.

How do developers test locally?

A DoH virtual site through a local proxy or an MDM profile puts the laptop under a development policy with a short hold.

What about agents that spawn containers?

They inherit the Docker daemon default. Set it to the sandbox policy; the Docker guide shows the file.

Put one agent under policy this sprint

A dnsConfig block, a week of Learn Only, and the review queue goes to the team that owns it.