interactive: tick items, your progress stays in this browser

AI Agent Security Checklist for Enterprises

48 checks to run before AI agents go live, grouped into eight areas. Each check says why it matters in one line.

Section 4 covers web access, the area most teams miss, where an AI agent allow list does the work.

Start the checklist Quick wins first

48Checks

8Areas

18Priority 1 checks

6Quick wins this week

The checklist

Eight areas, 48 checks

Tick what is already true. Priority 1 checks should be done before any agent reaches production.

Work through it with the agent's owner, someone from security and someone from the AI platform team. Most checks need all three to answer honestly.

Many checks are solved once for the whole platform. Web access at the egress proxy is the clearest example.

P1 before launchP2 within 30 daysP3 within 90 days

0 / 48

1. Inventory and ownership

0/6

Every agent is listed in one registerYou cannot protect agents you do not know exist.

Every agent has one named ownerSomeone must answer for each action and each review.

Purpose is written down per agentA clear purpose defines what normal behaviour looks like.

Agency level is recorded (answers, workflow, supervised, autonomous)Controls should grow with how much the agent may do alone.

Vendor agents acting for staff are recordedSaaS agents use your data and your name too.

Discovery runs regularly to find unregistered agentsTeams build agents faster than registers are updated.

2. Identity and credentials

0/6

Each agent has its own identityShared or personal credentials make actions untraceable.

No secrets inside prompts or agent configsPrompts end up in logs and model context.

Access is scoped to the taskBroad access turns any agent mistake into a big one.

Credentials expire within hours, not monthsShort lifetimes shrink the damage from a leaked key.

Test and production agents use separate identitiesA test leak should never open production.

Retiring an agent revokes every credential at onceForgotten keys are the most common machine identity risk.

3. Tools and MCP servers

0/6

Only approved tools and MCP servers are reachableUnreviewed servers bring unreviewed capabilities.

Approval is per tool, not per serverA server with one safe tool may also expose a dangerous one.

Write and delete tools need separate approvalReading mistakes are cheap; writing mistakes are not.

Third-party MCP servers are re-reviewed on new versionsA server can change what its tools do overnight.

Tool arguments are logged with each callThe arguments show what the agent actually tried to do.

Code execution runs in an isolated sandboxSandboxes limit what escaped code can reach.

4. Web access

0/6

Every URL is checked before the agent opens itAfter the page loads, the action may already have happened.

Signup, login and password reset pages are denied by defaultThese pages are where agents create or take over accounts.

Cart, checkout and subscribe pages are denied by defaultThese pages are where agents spend money.

Upload, post and comment pages are denied by defaultThese pages are where data leaves and content goes public.

High-risk hosts such as cloud metadata endpoints are always deniedOne request to these can expose credentials.

Unclassified destinations are denied for autonomous agentsDefault-deny stops the long tail of unknown sites.

Page types for 40M+ domains come from the page types database. Rules for risky URL patterns on any domain are in the egress rules library.

5. Data protection

0/6

Allowed data classes are set per agentAgents should only see the data their purpose needs.

Sensitive data is masked before it reaches the modelWhat the model never sees, it cannot leak.

Model providers' data terms are checkedKnow whether your prompts may be kept or used for training.

Agent memory has retention limitsStored memories can hold sensitive data long after a task.

Outputs are checked for sensitive data before sharingSummaries can repeat what the source contained.

Data sent to outside tools is approved by the data ownerTools can move data beyond your control.

6. Runtime protection

0/6

Content from web pages and files is treated as untrustedHidden instructions travel inside ordinary content.

Prompt injection detection runs on high-risk agentsDetection catches attempts to steer the agent.

Deterministic rules back up model-based checksRules give the same answer however the prompt is phrased.

Rate limits cap how much an agent can do per hourLimits slow down runaway loops and abuse.

A kill switch can stop any agent at onceEvery second counts during an incident.

Checks fail closed when a policy service is downAn outage should not open a gap.

7. Logging and response

0/6

Every tool call and URL decision is logged with the agent IDIncident reviews start with "what did it do, and where".

Logs reach the SIEM or central log storeSecurity teams need agent events next to other signals.

Alerts fire on repeated denied action attemptsRepeated denials are an early sign of drift or attack.

An agent incident playbook exists and has been testedAgent incidents move faster than human ones.

Logs are kept for at least twelve monthsMany issues are found long after they happen.

Owners review their agents' denials monthlyOnly the owner knows whether a denial was right.

8. Governance and assurance

0/6

A written agent policy is approved by leadershipControls need a mandate to survive delivery pressure.

Each policy rule names its enforcing systemA rule without enforcement is a wish.

Agents are red-teamed before releaseAttacks through web pages and files should be tested.

Agents are reviewed every 90 days and after changesTools and scopes drift over time.

Controls are mapped to a framework such as OWASP or NISTMapping shows auditors what is covered and what is not.

Monthly metrics go to a named committeeWhat gets reported gets fixed.

Quick wins

Six checks you can close this week

These six cut the most risk for the least effort. None requires new software beyond a page-type lookup.

4b to 4d: deny action pagesOne policy file, one page-type lookup. Takes effect the same day.

4e: deny high-risk hostsAdd the curated host list to your proxy or fetch tool.

2b: remove secrets from promptsSearch configs for keys and move them to a vault.

1b: name every ownerA spreadsheet is enough to start.

6e: test the kill switchStop one agent on purpose and time how long it takes.

7a: add the agent ID to logsEvery later check depends on it.

Web checks are the fastest because they need no change to the agent itself. The decision happens at the tool, gateway or proxy.

After the quick wins: a 30, 60, 90 day path

By day 30All priority 1 checks closed for every production agent. Owners named. Web action pages denied.

By day 60Priority 2 closed: short-lived credentials, per-tool approvals, alerts on repeated denials.

By day 90Priority 3 closed: discovery running, reviews scheduled, metrics reported monthly.

Scoring

What your score means

Count your ticks. Then read the band that matches your total.

0 to 15Not ready for agents that act. Keep them read-only until priority 1 is done.

16 to 28Pilot-ready with supervision. Close all priority 1 checks first.

29 to 40Production-ready for supervised agents. Plan the priority 3 work.

41 to 48Ready for autonomous agents, if reviews keep the score there.

The score is a guide, not a certification. One open priority 1 check can matter more than ten closed priority 3 checks.

Why checks usually fail

No owner for the areaWeb access and MCP servers often fall between teams.

Rules by domain, not page"Allow vendor.com" silently allows its signup page.

Checks in the prompt only"Never sign up for anything" is an instruction, not a control.

Logs without agent IDsEvents cannot be tied back to the agent that caused them.

One-off reviewsA launch review without follow-ups misses drift.

Vendor agents skippedNobody asked the vendor the questions in areas 4 and 5.

Who owns what

Assigning the eight areas

Area	Usual owner	Typical tools
1. Inventory	AI governance or platform team	Register, AI-SPM discovery
2. Identity	Identity and access team	Identity platform, NHI tools, vault
3. Tools and MCP	AI platform team	MCP gateway, tool allowlists
4. Web access	Network security	Egress proxy, page-type data, host list
5. Data	Data protection team	DLP, masking, data catalog
6. Runtime	Application security	Runtime protection, sandboxes
7. Logging	Security operations	SIEM, observability
8. Governance	Risk and compliance	GRC or AI governance platform

Area 4 is often nobody's job, because it sits between the AI team and network security. Assign it explicitly.

Network security already runs URL filtering for people. Extending it to agents with page types is usually the shortest path.

Using this checklist

How teams run it

The checklist works best as a living document. These four patterns cover most organisations.

Pick one owner for the checklist itself, usually the AI governance lead, so updates and scores stay consistent across teams.

Per agent, before launchThe owner ticks the list with the platform and security leads in one meeting.

Per platform, onceMany checks are solved centrally, such as web access at the proxy. Tick them once for all agents.

Quarterly, as a reviewRerun it to catch drift, new tools and new agents.

For vendorsSend areas 2, 4, 5 and 7 as questions to vendors whose agents act for your staff.

By agent type

Which areas weigh most for which agent

Agent type	Heaviest areas	Checks not to skip
Research agent reading public sites	4 Web, 6 Runtime	4a to 4d, 6a
Browser or computer-use agent	4 Web, 2 Identity	4b, 4c, 4f, 2b
Coding agent	3 Tools, 2 Identity	3c, 3f, 2b, 4e
Customer support agent	5 Data, 7 Logging	5a, 5e, 7a
Sales or procurement agent	4 Web, 5 Data	4b, 4c, 5f
Vendor SaaS agent	1 Inventory, 8 Governance	1e, 8b, plus vendor answers for 4 and 5

Web access shows up for four of the six types. Any agent that can open a URL needs area 4.

Coding agents are the exception to watch. They mostly read documentation, but package installs and uploads are writes, so check 4d still applies.

Evidence

What proves each area is done

Area	Evidence to keep
1. Inventory	Register export with owners and review dates
2. Identity	List of agent identities with credential lifetimes
3. Tools	Approved tool and MCP server list with approvers
4. Web access	Policy file and a sample of allow and deny log lines
5. Data	Data classes per agent and masking rules
6. Runtime	Kill switch test record and fail-closed settings
7. Logging	Log retention setting and one incident drill report
8. Governance	Signed policy and the last monthly metrics report

If you cannot show the evidence, leave the box unticked. An honest 30 is worth more than a hopeful 45.

Keep the evidence next to the agent's register entry, so the next reviewer finds it in one place.

Which checks would have mattered in 2026?

4d (deny upload and post pages) and 4f (default-deny) would have hit the wiki and dataset incidents.
4b (deny login and signup) would have hit the account takeovers where entry ran through those pages.
In our replay, page data plus egress rules would have stopped almost all of the incidents.

How the Hugging Face breach could have been stopped, and the rest The Hugging Face case

The honest fine print — the same two assumptions we publish, plus two operational ones

The policy engine must see every request — an agent with raw socket access or a second network path bypasses everything; enforcement belongs at the egress proxy/network layer, not only in an SDK hook.
Default-deny must be on. In flag-only mode these become alerts within minutes rather than prevention — still a large improvement on a timeline measured in weeks (the DseWiki edits ran from late May to late June 2026, per the researchers), but not a block.
For full URL+method matching on HTTPS you need to be the proxy or in-process hook — SNI alone shows only the host, which still catches the entire host-list layer.
Policy can’t read intent inside a legitimately allowed action: an agent whose job is publishing packages keeps registry access. In our replay of the 2026 incidents, no crossing fits any plausible allowlist for the agents’ documented tasks.

Keep reading

Governance framework template

The policy behind area 8.

Default-deny policy design

How to roll out check 4f safely.

Agent navigation audit logs

What to log for check 7a.

AI Tools Blocklist

The same idea for people using AI tools.

FAQ

Checklist questions

What should an AI agent security checklist include?

Inventory and ownership, identity and credentials, tools and MCP servers, web access, data protection, runtime protection, logging and response, and governance. This page has 48 checks across those eight areas.

Which checks matter most before launch?

The 18 priority 1 checks, including one owner per agent, no secrets in prompts, approved tools only, pre-request URL checks and denying login, signup, checkout and upload pages.

Is my progress saved?

Ticks are stored only in this browser on this device. Nothing is sent to us. Use Print to keep a copy.

How do I close the web access checks?

Check each URL's page type before the agent opens it and deny the action types. An AI agent allow list provides page types for 40M+ domains, plus a high-risk host list and URL rules.

Does this checklist cover vendor agents?

Partly. Use areas 2, 4, 5 and 7 as questions for vendors whose agents act for your staff, and record their answers in your register.

How long does it take to complete the checklist?

For one agent on a prepared platform, a single meeting. For a first agent on a new platform, expect several weeks, mostly for identity and logging work.

Can we launch with some checks open?

Only priority 2 and 3 checks, with dates to close them. Launching with an open priority 1 check means accepting that risk in writing.

Is this checklist based on a standard?

It draws on the OWASP agentic threats, the OWASP NHI Top 10, NIST AI RMF and the AWS agentic AI security scoping matrix, turned into concrete checks.

How do I test page-type data?

Download the free 100-domain sample, then use the lookup API from $99 a month. See pricing.