How to Integrate AMI With Your Existing Security Stack for Automated Threat Response

The most common question we hear from security engineers is not about detection accuracy or investigation quality. It is simpler: how hard is this to wire in? This guide answers that question in concrete terms — what AMI connects to, how the setup actually works, and how much control you keep at every step.

What "integrating AMI" means

AMI plugs into the stack you already have. It ingests alerts from your detection layer, gathers enrichment from your intelligence sources, and executes response through the controls you already trust — your EDR, your firewalls, your ticketing. Nothing is replaced, and no detection rule needs rewriting. If your stack works today, it works with AMI tomorrow.

Under the hood, every integration does one (or more) of three things:

• Actions — investigation and response tasks AMI can run against the tool, such as querying for host details or containing an endpoint.
• Alert intake — pulling the alerts a tool raises into AMI for autonomous investigation.
• Both — many connectors, including most SIEM and EDR integrations, supply alerts and accept actions.

When you configure a connector, the setup wizard adapts to what that connector supports — an intake-only threat feed asks different questions than a full EDR integration. That capability model is worth keeping in mind, because the rest of this guide follows it.

The integration map

It helps to think about your stack in terms of the role each tool plays in an investigation rather than its product category.

Alert sources sit at the front. SIEMs — Splunk, Microsoft Sentinel, IBM QRadar, Elastic — remain your detection and log layer; AMI subscribes to what they find. EDR platforms — CrowdStrike Falcon, Microsoft Defender, SentinelOne, Carbon Black — contribute endpoint detections. Cloud security tools — AWS Security Hub, Azure Security Center, Google Security Command Center, Prisma Cloud — bring posture findings and cloud-native alerts into the same queue.

Enrichment sources answer AMI's questions mid-investigation. Reputation and threat intelligence come from the likes of VirusTotal, AbuseIPDB, ThreatFox and GreyNoise; vulnerability context — is this host actually exposed to what the alert implies? — from Tenable, Qualys or Rapid7.

Response and workflow surfaces are where investigations end in action: host isolation through your EDR, IP and domain blocking through Palo Alto Networks, Fortinet, Check Point or Cisco firewalls, tickets in Jira, and notifications through Teams, Slack or email.

AMI ships with 100+ native integrations across these roles. The full catalogue, with connector-level configuration detail, is available to customers.

Before you start

A short amount of preparation makes the first integration smooth:

• Create dedicated service accounts for each tool AMI will connect to, granted the minimum permissions the connector needs. Shared admin credentials work in a lab; they have no place in production.
• Gather credentials and endpoints per connector — API URLs or tenant endpoints, client IDs and secrets, tokens.
• Decide where actions should execute. This is the Action Runner's job.

The Action Runner is a lightweight Docker container deployed inside your own network — launched from a generated .env file or a single command — that executes actions on AMI's behalf. Its connectivity is outbound-only: nothing in your environment is exposed to the internet, and the runner reaches out to CounterShadow rather than the reverse. Each runner reports a heartbeat to the console so you can see its health at a glance, and its authentication token can be rotated at any time.

Runners are scoped to an Area, which means a runner can only act within the environment it is assigned to. Areas suit organisations that segment operations by business unit, region or customer — if that describes you, our MSSP whitepaper covers the multi-tenant model in depth.

Step 1 — connect an alert source

Adding an integration is a guided, step-based wizard. Here is the real sequence:

1. Choose a connector from the catalogue. Search by name or browse by category.
2. Review its capabilities. The wizard shows whether the connector supports actions, alert intake, or both, and adjusts its steps to match.
3. Name it clearly. Give the integration a unique name that identifies environment and purpose — Production SIEM beats splunk-test-2. Add a description that explains what the connector provides, and assign it to the right Area.
4. Enter authentication. The fields depend on the connector. Two worked examples: Splunk connects through its REST API URL (typically port 8089) with a username and password, or a bearer token if you prefer token-based auth. CrowdStrike Falcon Insight XDR takes the API base URL for your cloud region plus an OAuth2 client ID and secret. Required fields are validated before you can deploy.
5. Configure alert intake. For connectors that supply alerts, you select the intake runner, set collection parameters, and define deduplication and filtering rules — so AMI receives the alerts you want investigated, once each.

You can save the integration as a draft at any point — useful when credentials are owned by another team — and return to finish it later.

Step 2 — choose actions and set autonomy per action

This step is why the integration model matters. AMI's autonomy is not a single global switch; it is set per action, per integration.

Actions fall into categories — query actions that read data, response actions that change something, notification actions that tell someone, and data processing actions that shape results. For each action a connector offers, you choose one of two modes:

• Autonomous — AMI runs the action automatically whenever an investigation calls for it.
• Semi-Autonomous — the action requires human approval before it runs.

The product's own guidance is deliberately conservative: query and notification actions suit autonomous use, while response actions should stay semi-autonomous until your approval and rollback processes are mature. Response actions change the state of systems, users or infrastructure — including, where your EDR supports it, remote command execution on a host — which is exactly why they sit behind an approval gate until you decide otherwise.

CrowdStrike's Contain Host is the flagship example. Set to semi-autonomous, AMI completes its investigation, concludes a host should be isolated, and queues the containment for one-click approval with the full evidence trail attached. Set to autonomous, the same containment happens the moment the verdict lands. And because Lift Containment is an action too, the response is reversible — isolation is a step you can walk back, not a one-way door.

There is no correct universal setting. The point is that the dial exists, it is per-action, and you own it.

Step 3 — test before you deploy

Nothing goes live untested. When the wizard steps are complete, AMI opens a built-in test workflow:

1. Select an Action Runner that has network reach to the target system.
2. Pick a safe test action. A query action — check cluster health, search recent alerts — validates connectivity without touching anything.
3. Run it and read the outcome. Successful means the integration responded correctly. Failed means network, credentials or permissions need attention. No meaningful data returned usually means the connection is fine but the query matched nothing — worth a second test with broader parameters.

Before you press deploy, a short checklist: the name, description and Area are correct; authentication values are valid; action autonomy settings match your security policy; alert intake is configured if the connector collects alerts; and the selected runner can reach the target environment. Then deploy — the integration is live and AMI can use it.

Step 4 — from first alert to first autonomous response

With an alert source deployed, the next alert it raises starts an autonomous investigation — typically running end-to-end in around 8 minutes. AMI plans the investigation, queries your stack for evidence, enriches indicators, correlates what it finds and reaches a verdict.

Your analysts see all of it: the evidence gathered, the reasoning behind each step, the verdict, and a log of every action taken or proposed. That transparency is what makes the trust curve practical. Most teams start with every response action semi-autonomous, watch AMI's judgement across real investigations, then graduate individual actions to autonomous as confidence builds — quick wins like enrichment and notification first, containment when the approval history shows it would have been right anyway.

Flows are the optional final layer. AMI investigates and responds with no flows defined at all — they exist for the parts of your process that must be deterministic rather than reasoned: compliance steps, approval chains, ticket creation, response orchestration. Flows are visual, no-code workflows with entry points around the investigation lifecycle — before investigation starts, after it completes, after response, and at completion — so you can bolt fixed business steps around AMI's autonomous work without constraining the investigation itself.

Keeping it healthy

Integrations are living configuration, and a little hygiene keeps them reliable:

• Re-test after change. Credential rotation, endpoint moves, runner reassignment — each is a one-click re-test away from confidence.
• Rotate secrets on your schedule, and rotate runner tokens immediately if a runner host is ever compromised.
• Keep least privilege honest. Service accounts should hold only the permissions their enabled actions need — if you disable an action, its permissions can go too.
• Match runners to network boundaries. Deploy runners inside the segments where their target systems live, and restrict egress so each runner reaches only the services it needs.
• Use drafts for staged rollouts, and disable an integration outright when a tool is being migrated rather than leaving stale credentials in play.

See it in your own stack

The honest summary: if you have credentials to hand, you can take your first integration from catalogue to tested and deployed in a single sitting, with every response action safely behind approval until you choose otherwise.

The fastest way to evaluate the fit is with your own tools and your own alerts — contact us to arrange a demo against a stack like yours. If the economics matter more than the wiring right now, the ROI calculator models what autonomous investigation of every alert would mean for your operation. And for shorter answers on how AMI relates to your SIEM and SOAR, see the FAQ.