Skip to content
AgenticCyber
Published

Base practices for securing agentic AI, by NIST CSF function

  • NIST CSF
  • governance
  • agentic AI

I organise every project on this blog around the six functions of the NIST Cybersecurity Framework 2.0. I collected the base practices in one place, so each project can point back here instead of repeating them.

I wrote them for agents that call models, tools and other agents. None of them depends on a product. A gateway is one way to implement several of them at a single point.

Govern

Who owns this and what are the rules?

  • Assign ownership: every agent, tool server, model and policy has a named owner and a risk tier.
  • Write the rules of use: which data may go to which model, which actions need a human approval.
  • Change policy only through review: pull request, second reviewer, CI validation, pipeline deploy.
  • Control the supply chain: an approved catalogue of models and MCP servers, pinned and reviewed before upgrade.
  • Gate onboarding: a team publishes through the gateway only after registering its agent and tools.
  • Keep evidence and report: Git history answers "who allowed this and when".

Identify

What do I have and what can go wrong?

  • Keep a live inventory generated from gateway configuration and logs, not a spreadsheet.
  • Find shadow usage: teams calling model APIs or MCP servers directly.
  • Classify tools (read-only, writing, destructive) and data by sensitivity; flag agents that combine untrusted input, private data and a way to send data out.
  • Threat-model every agent path before go-live with one template.
  • Measure the baseline and repeat after each significant change.

Protect

What stops a bad action?

  • Give every agent its own short-lived identity from the corporate identity provider; no shared keys.
  • Least privilege on tools: deny by default, allow per agent, human approval for destructive actions.
  • Hold provider keys centrally and rotate them.
  • Limit rate and spend per identity.
  • Inspect content in both directions; start rules in audit mode, then enforce.
  • Close the bypass: the gateway must be the only route to models and tools.
  • Train the people who build and review agents.

Detect

How do I know something happened?

  • Centralise gateway logs in the security monitoring platform.
  • Define a short list of alerts from a baseline: bursts of denied calls, any guardrail rejection, first use of a tool, repeated rate-limit hits.
  • Watch cost and volume per agent.
  • Trace end to end with OpenTelemetry.
  • Keep an audit trail for decisions an agent contributes to.
  • Test the detections on a schedule.

Respond

What do I do about it?

  • Write runbooks for agent incidents: stolen credential, malicious tool, prompt injection, runaway agent.
  • Prepare and test containment levers in advance: block one agent, hide one tool, close one route.
  • Revoke and rotate centrally.
  • Scope the incident from the gateway logs.
  • Record and communicate under an incident reference.
  • Exercise it and measure time to contain.

Recover

How do I get back to normal?

  • Make everything rebuildable from Git through a pipeline.
  • Roll back by reverting a commit, then run automated control tests before reopening traffic.
  • Set recovery objectives and prove them with a timed rebuild.
  • Protect what is not in Git: keys and secrets.
  • Be able to undo what agents changed.
  • Feed lessons back into the rules, the threat model and the policies.

See them applied

In the agentic gateway project I implement a first version of each function on a local Kubernetes cluster and prove the controls with a script.

Securing agent traffic with an open-source agentic gateway →