Turn an Elastic Security detection into a host-level investigation, without giving AI shell access

Elastic Security saw new files appear where attackers hide persistence on web-1. Through Secronyx, Claude worked out what they add up to: a new user with an SSH key and a hidden script that runs as root every two minutes. It also showed that web-1's twin, web-2, has none of it. There was no shell access and no change to either host.

Request accessSee the investigation

This is a recorded run in AWS, not a mock-up. An Elastic Security detection rule fired, Kibana sent the alert to Secronyx, and Claude, Anthropic's AI assistant, picked up from there. We recorded it on 12 November 2026 in AWS's London region. All times are UTC.

The problem

• A detection says where to look, not what it means. The rule saw files created under /etc/systemd/system and an authorized_keys file. It can't say what runs, as whom, how often, or whether the host's twin looks the same.
• Giving an AI a shell is too risky. A shell can change anything and read anything. You don't hand that to an AI on a production server.
• There's no trail of what the AI looked at. When an AI reaches a verdict, you need to know what it saw, on which host, and who allowed it.

The investigation: a foothold on web-1

We planted a harmless stand-in for an attacker's foothold on web-1, one of two identical web servers. It has three parts:

• a local user, backup-sync, with an SSH key whose private half we deleted at once, so nobody can use it;
• a script in a hidden directory under /usr/local/lib;
• a systemd timer that runs the script as root every two minutes.

The script only writes the date to a file. The user has no sudo rights, and nothing is reachable from outside. Auditbeat on both web servers sends file, user and process events to Elasticsearch.

In the screenshots, teal boxes mark Secronyx. Tool names are blanked.

The detection rule. It runs every minute over the Auditbeat data, and its one action posts each run's alerts to the Secronyx alert bridge through Kibana's Webhook connector.

We planted the stand-in at 11:19:05. At 11:19:55 the rule raised four alerts on web-1: the SSH key, the service, the timer and the timer's link.

At 11:19:58 the alert reached the Secronyx alert bridge on the fleet proxy. The bridge matched the rule's name to the persistence-sweep playbook and ran its 9 read-only checks on web-1. By 11:20:10, twelve seconds later, every result was signed by web-1 and saved as an evidence case.

At 11:20:33 we started Claude with two tools only: Kibana's MCP server, limited to its read tools and a read-only key, and the Secronyx fleet proxy for the hosts. No shell and no file access. Nobody steered it after the first prompt. It read the alerts and the Auditbeat events, read the bridge's results, went further where the evidence pointed, compared web-1 with web-2, and wrote its report at 11:23:19. It made 33 calls: 25 to Secronyx and 8 to Kibana.

Its verdict was likely compromise on web-1, and it named:

• the new user, its UID, that it has no admin rights and that no login by it is recorded;
• the hidden script's path, size and hash, and that no package owns it;
• the timer, enabled, running the script as root every two minutes;
• that the only remote execution it could see was AWS Systems Manager Run Command, which is how we planted it;
• that web-2 has no such script or timer.

It also found two things the alerts didn't mention, and both are real:

• Our rehearsal. We ran the scenario once ten minutes earlier, removed it, then planted it again for the recording. Claude saw the user added, removed and added again, and that the SSH key's hash changed between the two, because each run makes a new key.
• Our previous demo. web-2 held the stand-in from our Alertmanager demo an hour earlier. Claude found that its two files had been deleted at 10:44, when we cleaned up, and flagged them for a person to look at.

Claude's report, unedited apart from the blanked tool names.

It was also clear about its limits:

• It could not read the script or the key, because Secronyx doesn't return file contents.
• It could not read auth logs or sudoers, which need a scope this policy doesn't give the AI.
• It could not see which process created the files, because no process-execution auditing was set up. It listed the CloudTrail and Systems Manager records a person should check instead.
• One Kibana tool returned "No connector available" (we hadn't set up an AI connector in Kibana), so Claude queried the alerts index with ES|QL instead.

It proposed preserving evidence, finding out who ran the Systems Manager commands, and containing web-1 before removing anything. It changed nothing, because Secronyx can't change a host.

What Secronyx proves

What the AI actually saw

Before a host runs anything, it checks a single-use pass signed by the fleet proxy, naming the caller and the rule that allowed the call. The host then writes the call to its own tamper-evident audit log. web-1's log shows the bridge's 9 checks, then Claude's 10 follow-ups, each under its own rule.

web-1's audit log. Each call names who it was for (the alert bridge or the AI investigator), the run and the rule that allowed it.

What it wasn't allowed to see

pci-db-1, a database host labelled as holding card data, is reserved for the security team. On the fleet it is outside Claude's access, and Claude stayed on the two hosts its access covers. pci-db-1's own audit log has no calls from this investigation, because nothing reached it.

Evidence you can check later

The bridge's evidence case can be checked offline by anyone with secronyx evidence verify. It checks the proxy's signature, the fingerprint (hash) of every result and web-1's signature on its own results. All 20 findings verified. Then we changed one stored result, renaming backup-sync to backup-sinc, and verification failed, naming the result.

Green: the case verifies. Amber: change one letter in one stored result and it fails.

Why Secronyx alongside Elastic Security

Elastic Security detects and Claude does the reasoning. Secronyx provides the controlled, read-only access to host-level evidence, with independently verifiable records of every investigation.

• Evidence within seconds of the alert. The bridge runs a fixed playbook as soon as the alert arrives, before anyone opens a laptop, so the evidence reflects the moment it fired.
• Questions nobody shipped data for. The detection fired on file events. Secronyx could also say what the timer runs, as whom, whether a package owns the script, and what the twin host looks like now.
• No model inside the product. The bridge is deterministic. Any AI that speaks MCP can pick up from its results, and so can a person.
• One Webhook connector. Kibana needs no plugin: a standard Webhook connector with its own key, which can post alerts and nothing else.
• A label policy decides what each caller may see, the bridge and the AI alike, and restricted hosts stay invisible.
• Every check is in the answering host's own audit log, and the results are signed so they can be checked long after the incident.

Why not just run a script from the alert?

Kibana can call any webhook, so a team could point it at a script that logs in to the host and runs commands. That works, but it moves the risk rather than removing it.

How it fits together

The bridge and Claude talk only to the Secronyx fleet proxy, which passes read-only checks to the hosts each of them may see. The hosts connect out to the proxy, so none of them opens a listening port.

How it's set up

1. Install Secronyx on each host. Here that's three EC2 instances: web-1 and web-2, the web tier, and pci-db-1, a database labelled as holding card data. Auditbeat on the web servers sends file, user and process events to Elasticsearch.

2. Run the Secronyx fleet proxy with the alert bridge. One config file maps each rule name to a playbook and the alert's instance label to the host.

3. Write the label policy. The bridge and the AI may see hosts labelled env=demo. Hosts labelled data=pci are reserved for people in the secops group.

4. Add a Webhook connector in Kibana that posts to the bridge with its own key, and use it as the detection rule's action. The body is a small JSON template:

   {"alerts": [{"status": "firing",
     "labels": {"alertname": "{{context.rule.name}}", "instance": "{{context.alerts.0.host.name}}", "env": "demo"},
     "annotations": {"summary": "{{context.rule.description}}"},
     "fingerprint": "{{context.rule.id}}"}]}

   The connector posts to https://fleet-proxy.example.com/integrations/webhook/alerts. Kibana's Webhook connector needs an Elastic subscription that includes it; we used Elastic's 30-day trial.

5. Connect your AI. Claude Code connected to the fleet proxy as an MCP server with a key in the ai-investigators group, alongside Kibana's MCP server with a read-only API key.

Try it on your fleet

Secronyx is in beta. Tell us about your fleet and we'll help you connect it to Elastic Security.

Request accessTalk to us

Read more: fleet deployment · the Alertmanager demo · the Grafana demo · the AWS DevOps Agent demo

Elasticsearch and Kibana are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries. MITRE ATT&CK is a trademark of The MITRE Corporation. Claude is a trademark of Anthropic. AWS is a trademark of Amazon.com, Inc. or its affiliates. Other names are trademarks of their owners. Secronyx is not affiliated with, sponsored or endorsed by Elasticsearch B.V., The MITRE Corporation or Amazon.