Securing AI assistants and agentic tooling.

Five core operator practices

If you run AI assistants or agents in any environment that touches real data or systems, these five practices carry most of the weight. Everything later in this guide refines them.

1. Least privilege.Grant each assistant, agent, and integration the narrowest scope it needs and nothing more. Prefer read-only by default; gate write, delete, and spend behind explicit, scoped grants. Re-review scopes on a schedule and remove anything unused.
2. Secret management.Keep credentials out of prompts, source code, and client-side bundles. Inject them at runtime from a secrets manager or environment, scope them tightly, and rotate on a defined cadence. A secret that never appears in a model context can't be leaked through one.
3. Logging & audit.Record who or what invoked which tool, with which inputs and outputs, and when. Make logs tamper-evident and queryable. You cannot investigate, detect drift, or prove what happened without a reliable trail — and AI tool calls deserve the same scrutiny as any privileged action.
4. Retention controls.Decide deliberately what conversation data, tool inputs, and outputs are stored, where, for how long, and who can read them. Default to minimal retention. Disable training-on-your-data where required and document the decision.
5. Human-in-the-loop for high impact.Require explicit human confirmation before any irreversible or high-blast-radius action — money movement, production writes, deletions, external communications, or privilege changes. Automation is fine for low-risk steps; keep a human gate on the dangerous ones.

Zero-trust applied to AI tooling

Zero-trust means no request is trusted because of where it came from. Applied to AI systems, this matters twice over: the model's inputs are frequently untrusted (web content, user uploads, tool outputs), and the model's requests to tools must be authorized per call rather than assumed safe.

STRIDE threat model for AI assistants

STRIDE is a structured way to enumerate threats by category. Walking each category against your AI assistant surfaces gaps quickly. The table maps each STRIDE category to a concrete AI-assistant example and a mitigation.

Secrets & API-key hygiene

The fastest way to lose control of an AI system is to leak the keys that drive it. Treat every API key, token, and credential as a live secret with a blast radius.

Rules of thumb

• Environment / secret store only. Load keys from environment variables or a managed secrets store at runtime. Never commit them to source control or embed them in prompts.
• Never in client code. Keys in browser bundles, mobile apps, or front-end config are effectively public. Keep all privileged calls behind a server you control.
• Scope tightly. Issue keys with the least privilege and narrowest resource access that works. Prefer per-service, per-environment keys over one shared master key.
• Rotate on a cadence. Rotate regularly and immediately on any suspicion of exposure or staff change. Automate rotation where you can so it actually happens.
• Revoke fast. Maintain a one-command path to revoke a key. The window between “possibly exposed” and “revoked” is your exposure.

A correct setup keeps the key on the server and out of any model context:

# .env — server-side only, never committed, never sent to a model
AI_API_KEY=sk-ant-XXXXXXXX-EXAMPLE-ONLY

# server code reads from the environment at runtime
key = env("AI_API_KEY")   # ✓ injected at runtime, server-side

# ✕ never do this — hard-coded in source or in a prompt
key = "sk-ant-XXXXXXXX-EXAMPLE-ONLY"   # ✕ committed / exposed

Prompt injection & data exfiltration

Prompt injection is the signature AI threat: untrusted content (a web page, an email, a file, a tool's output) carries instructions that the model may follow as if they came from you. The goal of an attacker is usually to exfiltrate data or abuse a tool.

Where injection enters

• Untrusted content the model reads — fetched web pages, uploaded documents, retrieved knowledge-base chunks, third-party API responses.
• Tool outputs that flow back into context, which an attacker may have influenced upstream.
• User-supplied fields in multi-user systems, where one user's input becomes another's context.

MCP server & tool security

When an assistant connects to tool servers (for example, via the Model Context Protocol), each connected server is a new trust boundary and a new attack surface. Secure them like any service exposing privileged actions.

Incident-response checklist

When something goes wrong — a leaked key, a successful injection, an unexpected privileged action — move through these steps in order. Decide ownership and thresholds for each step before an incident, not during one.

1. Detect.Confirm the incident from logs, alerts, or a report. Establish scope: which keys, agents, tools, data, and time window are involved.
2. Contain.Stop the bleeding — disable the affected agent or tool, cut egress, suspend the workflow, and isolate impacted systems so the issue can't spread.
3. Rotate credentials.Rotate or revoke every key, token, and secret that may have been exposed. Assume exposure if you can't prove otherwise.
4. Preserve logs.Snapshot and protect relevant audit logs, prompts, tool I/O, and system state before they age out or are overwritten. Preserve the evidence.
5. Notify.Inform the right internal owners and, where required, affected parties — following your own legal and policy obligations. Confirm those obligations with qualified counsel.
6. Post-mortem.Run a blameless review: root cause, what controls failed, what would have caught it sooner, and concrete fixes with owners and dates.

Mapping to common frameworks

The practices in this guide align in spirit with widely used security frameworks. The notes below are high-level orientation only — they are not control mappings, and they do not assert or establish compliance. For an actual assessment, work from the source standards with qualified guidance.

NIST Cybersecurity Framework (CSF)

This guide aligns with the spirit of the CSF's high-level functions — identifying assets and risks, protecting them with least privilege and secrets hygiene, detecting through logging and monitoring, and responding and recovering via the incident-response process in Section 07.

CIS Controls

It echoes the intent of the CIS Controls' emphasis on inventory and control of access, secure configuration, account and credential management, audit logging, and a defined incident-response capability — applied here to AI assistants and tool servers.

ISO/IEC 27001

At a high level, the approach here is consistent with the spirit of ISO/IEC 27001's information-security management mindset: risk-based controls, access management, operational logging, and continual review — adapted to AI tooling rather than treated as a certification claim.