Cyber hygiene for AI agents.

Cyber hygiene for AI agents means keeping their tools, permissions and working environments under review as they change. That includes knowing what is installed, limiting credentials and access, checking dependencies, maintaining configurations and testing that the intended restrictions still hold.

An engineering team adds an AI agent to its incident workflow. The agent can inspect logs, query a database and prepare a fix. It also inherits a cloud credential from the environment where it runs. The team has documented the task, but nobody has checked everything that credential allows.

In this hypothetical workflow, a routine investigation now has access to production. Before expanding the task, the team needs to inspect that credential and remove permissions the investigation does not use.

The NSA’s September 2026 Best Practices Guide for Cyber Hygiene describes adversaries using AI to accelerate intrusion techniques that exploit familiar weaknesses: missing patches, weak authentication and misconfiguration. It emphasizes inventory, multifactor authentication and patching, followed by improvements such as segmentation and continuous monitoring. Its maturity tiers start with immediate risk reduction. The agency also states that these measures do not address every attack vector.

This article uses the guide as a starting point for agentic security: the recurring work needed to maintain the systems through which agents act. The examples and checks below are Oktsec’s proposals, not NSA requirements or results from a customer engagement.

Build the basics before automating the response

Before an agent can safely help respond to incidents, the team needs an accurate inventory, scoped access and working logs. Then it can test automated responses and practice recovery. The NSA organizes this work into four stages. Here is what each stage involves.

Four stages of cyber hygieneBuild the controls before relying on automated response

1. Tier 0
   Reduce immediate exposure

   Inventory assets and access, patch software, strengthen authentication, verify log collection and restrict unnecessary paths.

   Also included

   Approved application lists, endpoint detection and tested incident response.

2. Tier 1
   Prepare and test integrations

   Plan response automation, improve logging and alerting, and test network isolation.

   Check

   Hidden connections must not bypass the intended separation.

3. Tier 2
   Validate automated responses

   Implement selected responses in controlled environments and connect them to security systems and workflows.

   Document

   Make procedures repeatable and retain human involvement where appropriate.

4. Tier 3
   Exercise the defenses

   Use adversarial emulation and assessments, address the gaps and exercise recovery.

   Continue

   Keep looking for signs of intrusion and retest the controls.

Before allowing an automated response to isolate a service, establish what the agent observes, how the response is authorized, what happens if the action fails and who restores service. A successful detection does not establish that a proposed response is safe to execute.

The NSA reports testing these measures against AI-generated attack plans and vulnerabilities identified with AI. It does not publish success rates or a reproducible test set. Teams still need to verify the controls in their own environment.

An inventory should explain what an agent can reach

A useful inventory connects devices and software to accounts, permissions, network paths, owners and recovery procedures. For an AI agent, it must also identify the tools and service identities used to carry out a task. Keep credential references and access metadata in that inventory; do not put raw passwords or tokens into an AI prompt or ordinary asset export.

A laptop inventory may tell you that a developer uses an AI coding assistant. It may not tell you which MCP servers the assistant connects to, which skills it loads, or which account a tool uses to access a production service.

MCP, the Model Context Protocol, connects agents to tools and data. A skill supplies instructions and may refer to scripts or other resources. Both belong in the review of the agent’s working environment. So do shell access, network access and credentials available outside MCP.

For our incident-response example, record the assistant, its harness, connected tools, installed versions or resolved commits, service identities, and permitted destinations. Assign an owner to the workflow and record when each component was last observed.

Then ask a concrete question: can the incident agent query a test database, a production database, or both? A list of application names cannot answer that. The answer requires configuration and permission evidence from the services involved.

Swipe or scroll horizontally to compare all columns.

Missing data needs its own state. A connector with an unknown version cannot be cleared by a version-based vulnerability check. A computer that stopped reporting has not proved that its tools were removed. Our agent discovery overview explains why this visibility matters before teams expand access.

Translate familiar weaknesses into agent workflows

Excessive privileges, missing logs, open network paths and unrestricted scripts can turn an agent’s mistake into a wider incident. These examples show what to check; they are hypothetical, not reported customer incidents.

Swipe or scroll horizontally to compare all columns.

A valid identity can still have too much access

Human authentication and tool authorization solve different parts of the problem. An employee may sign in securely while the agent they launch inherits a service token with permission to export an entire customer database.

For the incident task, give the agent a dedicated identity with the minimum data access needed to investigate. Keep the ability to change production configuration or restart a service in a separately controlled path. Limit credential lifetime and scope where the destination supports it.

Also test the permitted operation’s parameters. Allowing a database tool by name does not distinguish a query for one incident from a bulk export. Allowing a file tool does not establish which directories it may read.

An instruction in a prompt cannot revoke a token’s permissions. The restriction must hold where the action happens: in the destination service, operating system, network control or configured tool enforcement point. This is the practical connection to our work on prompt injection and authorization.

Keep checking after a tool is approved

A connector can be acceptable when installed and need attention later. A new advisory may affect its version. An update may request broader permissions. A skill revision may introduce a script that sends files to an external service.

These are different reasons to review a component. An old version is not automatically vulnerable. A vulnerability match does not establish that exploitation happened. Risky instructions may deserve investigation without any CVE identifier.

Useful monitoring connects the new information to an observed installation. An alert should identify the source, component, affected computers, observation date and next action. It should also say what is unknown. A failed check must not become a clean result.

For example, if an advisory affects the incident agent’s connector, the owner needs to know which installations match, whether a fixed version exists, and whether access should be restricted while the update is tested. Closing the change ticket is not proof that the new version reached every computer.

Oktsec Signal brings inspection of agent tooling into this process. When evaluating continuous monitoring, verify the sources, resource types and collection paths available in the deployed version. Local inspection, advisory matching and continuous evaluation of skills are distinct capabilities. Check which employee computers and tool types are covered, when they last reported and who receives the alerts.

Our guide to AI coding agent security follows these checks through a software change, including how to distinguish a vulnerable dependency from a risky instruction.

From a change to a verified correctionA connector advisory appears. What happens next?

1. 01 / DetectMatch it to installed tools

   Check the package, version, affected computers and age of the inventory.

2. 02 / ReviewCheck access and impact

   Confirm the advisory’s conditions and what data or systems the connector can reach.

3. 03 / ActAssign and apply the correction

   The owner updates the connector or restricts its access while a fix is tested.

4. 04 / VerifyObserve the change and retest

   Confirm the installed version. Check that the required task works and the prohibited action fails.

Correction verified

Close with the observation, test result and owner recorded.

Evidence missing or test fails

Keep the issue open. Return it to the owner with the missing check.

Give defensive AI evidence and a limited role

AI can help examine inventory and logs, identify unusual activity and suggest which issues to investigate first. The NSA recommends human validation of that analysis and another check after a correction. The person reviewing a finding needs the underlying records, not just the model’s conclusion.

In practice, an assistant could correlate a connector advisory with installed versions and propose an investigation order. A reviewer should be able to trace each match to the package identity, affected range, observation date and source. If a version is missing, the assistant should report uncertainty instead of guessing.

Keep the authority to investigate separate from the authority to change the environment. Reading an advisory should not by itself permit an agent to disable a production integration or revoke a shared account. Test an automated response on controlled systems first, with defined approval, failure handling and recovery. Keep a named owner for approval and recovery.

Test the boundary with a task that should succeed

A control that blocks every operation may look effective while making the workflow unusable. Test both sides: the action the agent needs and the action it should not be allowed to perform.

In an isolated copy of the incident workflow, let the task identity query the permitted operational records. Then request a synthetic customer export with that same identity. Check the response and the receiving system’s logs. The legitimate query should work; the export should fail without transferring protected data.

Repeat the check through the other available tools. If the database connector denies the export but a shell can use the same credential directly, the workflow still has an open path. The tool-call walkthrough explains why the route matters.

Oktsec Assessment tests applications and agent workflows within an agreed scope, with reviewed findings and retesting. Keep the tested revision, identity, expected outcome and observed result. A plausible finding remains a candidate until the supporting evidence is sufficient.

Oktsec Control applies policy to actions routed through configured integrations. It complements the environment’s own permissions. It does not replace endpoint protection, identity management, patching or network segmentation, and it cannot enforce policy on a path that bypasses it.

Keep a record that helps someone respond

Suppose the export was denied. An investigator needs to know which identity requested it, what target was involved, which policy was evaluated, what decision was made and whether another route reached the destination.

Keep those records without placing credentials or customer records into the audit trail. Link the decision to the relevant inventory observation and receiving system’s result. A tool timeout may leave the outcome unknown: an authorization record alone cannot establish whether the operation completed.

Signed evidence helps check origin and integrity. It does not prove that every action was recorded, that a finding is correct, or that an organization meets a compliance requirement. The reviewer still needs to understand coverage, missing records and the control being tested.

Oktsec Cloud brings policy and review information together across reporting systems. For an audit or incident review, use those records alongside the destination’s evidence and the organization’s procedures. Our evidence guide explains what each record can establish.

What should a startup or enterprise do first?

Start with workflows that can reach customer data, production infrastructure or money. A coding assistant limited to a test workspace and a support agent that can issue refunds need different reviews. Prioritize by the actions available, the sensitivity of the data and the routes to other systems.

A small team can begin with one shared register and its existing issue tracker. Each workflow needs an owner, a list of identities and tools, a known way to stop new actions, and a test of one important access restriction. In a larger organization, connect the same information to endpoint inventory, identity management and the incident queue so ownership does not get lost between teams.

Swipe or scroll horizontally to compare all columns.

When should the review run again?

Review access before connecting a new service or giving an existing agent permission to write, deploy, export or pay. Recheck after connector upgrades, skill changes, new vulnerability disclosures and changes to service accounts. Set an expected reporting interval for each inventory source; investigate missed reports instead of carrying a clean status forward indefinitely.

For a team starting out, a weekly review of unresolved alerts and missing reports is a reasonable operating routine, alongside immediate triage of urgent exposures. This is our suggested starting cadence, not an NSA requirement or a response SLA. Workflows with production or financial authority need monitoring and escalation appropriate to their impact.

Track a few numbers the team can act on: sensitive workflows without an owner, installations whose version is unknown, overdue reports, and corrective actions awaiting verification. Give each unresolved item an owner and a next review date. Counting installed agents or closed tickets alone does not show whether access is controlled.

If the team accepts a risk temporarily, record who accepted it, why, the affected scope and when the decision expires. Keep it separate from a verified correction. That distinction prevents an exception from disappearing into a green dashboard.

What evidence is enough to close a correction?

For the incident agent, keep the identity and configuration tested, the permitted query’s result, the denied export’s result, and the destination’s corresponding records. After a tool update, add the observed replacement version. After a permission change, retest using the affected identity.

A founder, engineering lead or security reviewer should be able to answer three questions from that record: what changed, did the required work still succeed, and did the unwanted action stop? If any answer is missing, keep the item open or state the limitation explicitly.

Source and related analysis

• NSA: Cyber hygiene best practices against AI-enhanced targeting, September 3, 2026. Publication announcement; the accompanying eight-page guide was also reviewed.
• NSA cyber hygiene guidance — original PDF. September 2026, version 1.0. Source for the four stages, inventory categories, recurring configuration gaps and recommendations on defensive use of AI.
• How attackers use AI to keep operations running: a separate analysis of Anthropic’s reported cases, including credential abuse and repeated operational workflows.

This is independent Oktsec analysis. The NSA does not endorse Oktsec or the product mappings in this article.