Automating Security Checks with AI Agents, Without Handing Them the Keys

AI agents are now good enough to do a lot of the tedious work in a security assessment: running hundreds of read-only commands across dozens of servers, collating the output, comparing it against a baseline and writing up what they found. They are also capable of doing real damage if you give them broad credentials and let them act on their own conclusions.

This post describes how we use agents in security work, and the guardrails that make it safe. The short version: agents discover and draft, people decide and approve, and every action is logged. For the broader picture of agents in business systems, see AI agents in the enterprise.

What agents are good at

• Inventory at scale. Finding every PHP binary, every open security group, every IAM key older than 90 days, across many hosts and accounts, without getting bored on host 47.
• Running checklists consistently. The same checks, in the same order, in every Region, every time. Humans skip Regions; scripts and agents do not, if you tell them to loop.
• Reading and correlating output. Matching a package version against a list of fixed versions, spotting that a distro backport means an "old" version number is actually patched, and flagging the one host that does not match the others.
• Drafting. First drafts of findings, remediation steps, change requests and reports, with the evidence attached.

What agents are bad at

• Knowing your business context. An agent sees a public S3 bucket. It does not know that bucket serves your product images and that blocking it will break your storefront.
• Judging risk trade-offs. Restarting PHP-FPM in the middle of a payment run, or rotating a key used by an unmonitored cron job, is a business decision.
• Being certain. Agents can state wrong things confidently, including misreading a version string or inventing a flag. Every finding needs its raw evidence next to it so a person can check.
• Resisting manipulation. An agent reading log files, web pages or ticket text can encounter text written to look like instructions. This is prompt injection, and the defence is architectural: the agent should not have permissions that would make a successful injection harmful.

Guardrail 1: read-only credentials for discovery

Discovery runs under an identity that cannot change anything. On AWS that means a dedicated IAM role with the AWS managed SecurityAudit or ReadOnlyAccess policy, assumed for a limited session, ideally from a separate tooling account. Not an admin user. Not a long-lived access key.

Be careful with permissions that look read-only but are not. ssm:SendCommand lets you run any command as root on any managed instance. If you use Systems Manager to collect inventory from servers, restrict the role to a specific, reviewed SSM document that only runs inventory commands, scoped to the instances in question. Or use SSM Inventory, which collects installed package data without granting command execution.

Guardrail 2: least privilege for anything that changes

When a fix is approved, the change runs under a different, narrower identity that can do only that change. Patching PHP on a fleet needs permission to run one approved patch document on a named set of instances. It does not need IAM, S3 or billing permissions. Separating discovery and change identities also makes the audit log much easier to read.

Guardrail 3: change approval, with a human in the loop

Agents propose changes; engineers approve them. A good change proposal includes:

• What will change, on which resources, written as exact commands or a diff.
• Why: the finding and its raw evidence.
• Expected impact, including restarts and downtime.
• How to verify it worked, and how to roll back.

The engineer reviews the evidence, checks it against what they know about the business, and approves, edits or rejects. For production systems the customer approves too. No agent applies a fix to production on its own judgment.

Guardrail 4: audit logs for everything

Every command an agent runs, and its output, is logged on our side. On the customer side, CloudTrail records every AWS API call the assessment role makes, under a clearly named role and session, so the customer can see exactly what was done. If CloudTrail is not on, turning it on is usually our first recommendation anyway (see the AWS security baseline checklist).

Guardrail 5: data stays where it should

Assessment output can contain hostnames, IP addresses, user names and sometimes secrets that turn up in config files. Decide up front which model provider processes it, under what data-retention terms, and redact secrets before anything leaves the environment. We cover this in more depth in AI data privacy and governance.

Worked example: a PHP2Shell inventory

When PHP released fixes for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026, the first question for every affected business was simple: where is PHP running, and which versions? The answer is rarely just "the web servers". It includes old admin panels, cron hosts, containers built from old base images, and the WordPress site someone set up in 2018.

Here is how the agent-assisted version of that inventory works:

1. Scope. The customer lists the AWS accounts and any non-AWS hosts in scope. The agent gets a read-only assessment role in each account and nothing else.
2. Discover hosts. The agent lists EC2 instances, ECS services, EKS clusters, Lambda functions and Lightsail instances in every Region, and pulls Inspector findings for the two CVEs if Inspector is enabled.
3. Collect versions. On each host, a reviewed read-only script runs the same commands: binary versions, package manager listings, running processes and loaded SAPIs.
4. Compare. The agent compares each version against the fixed releases (8.2.35, 8.3.36, 8.4.27, 8.5.12), checks distro changelogs where a vendor may have backported the fix without changing the upstream version number, and flags end-of-life versions with no upstream fix.
5. Report. It produces a table of every PHP runtime with host, version, SAPI, patched or not, and the evidence for each line.
6. Human review. An engineer checks the anomalies, confirms the backport judgements, and decides the patch plan with the customer.

The per-host collection script is deliberately boring and read-only:

# Read-only: report PHP binaries, packages and running processes
for b in $(command -v php php-fpm php-cgi 2>/dev/null) /usr/sbin/php-fpm* /opt/*/bin/php; do
  [ -x "$b" ] && echo "$b: $("$b" -v 2>/dev/null | head -1)"
done
(dpkg -l 2>/dev/null | grep -i php) || (rpm -qa 2>/dev/null | grep -i php)
ps -eo pid,user,args | grep -E "php|httpd|apache2|lsphp|frankenphp" | grep -v grep

Only after the inventory is reviewed does anything change. Patching, restarting every PHP worker, and verifying the new version is actually loaded are separate, approved steps, run under a change identity with an engineer watching. The details of the vulnerability and the patch process are in PHP2Shell explained, and options for old PHP versions are in PHP2Shell and end-of-life PHP.

Questions to ask any provider using agents

• What credentials will the agent have, and can they change anything?
• Who approves changes, and can I see the proposal before it runs?
• Where is the assessment data processed and stored, and for how long?
• Will I get the raw evidence, not just the summary?
• How do I revoke access when the work is done?

If the answers are vague, the risk you are adding may be larger than the risk you are removing.

HashTech Systems uses this agent-assisted, human-approved approach for its PHP2Shell remediation service; see the PHP2Shell page.