Human-in-the-loop for security agents
Containment is a decision, not a trigger.
The on-duty analyst authorizes containment from their phone, and the authorization is saved with the incident.
How does a SOC AI agent get an analyst to authorize a containment action?
Pushary lets a SOC AI agent get an analyst to authorize a containment action from their phone. Put one call before the host isolation, the account disable or the block. The analyst taps Approve or Deny on the lock screen. Your agent waits for that answer instead of firing on a confidence score. If nobody answers in time, the containment does not run. Every authorization is saved to attach to the incident record.
What needs a yes
The calls that should not be automatic
- isolateHost(hostId)
- Pulling a machine off the network stops an intrusion. It also stops the person using it. On the wrong host during business hours, that is its own incident.
- disableAccount(userId)
- Disabling the wrong account locks out someone who was doing their job. A false positive here hits a real person right away, and they call the help desk within minutes.
- blockIndicator(type, value)
- Blocking an indicator that turns out to be a shared IP or domain takes down services that had nothing to do with the alert.
- revokeSessions(userId)
- Revoking every session is a fair response to stolen credentials and an unfair one to a noisy detection. Telling those apart is the analyst's job.
The code
One call inside the step you already have
Wrap the action, not the whole agent. Everything the agent does that is safe keeps running without asking anyone.
pip install pusharyimport os
from pushary import PusharyServer
px = PusharyServer(api_key=os.environ["PUSHARY_API_KEY"])
def contain(alert, action):
# Enrichment and evidence collection never wait for anyone.
context = enrich(alert)
if action.reversible and context.confidence > 0.95:
return apply(action)
decision = px.decisions.ask(
external_id=alert.duty_analyst_id,
type="confirm",
question=(
f"{action.summary} on {action.target}? "
f"Confidence {context.confidence:.0%}. Impact: {action.user_impact}."
),
)
if not decision["approved"]:
return annotate(alert, "containment not authorized")
return apply(action)Who answers
The approver is not at a desk
The approver is the analyst on duty, and out of hours that is one person covering a lot. The usual setup is a bot posting the containment in a channel with a button. That works by day. At 03:00, nobody may be reading that channel. Then the intrusion keeps going while the right decision waits. Pushary reaches the analyst's phone, by the id your duty rota already uses.
If we wait for a human, does the attacker not just get more time?
Sometimes, which is why you choose per action rather than per incident. Enrichment, evidence collection and anything you can cleanly undo should run now and be reviewed after. That covers most of what a SOC agent does. Gate the actions whose cost when wrong is close to the cost of the intrusion: isolating a production host, disabling an executive's account, blocking a shared service. For those, firing on a confidence score only moves the outage somewhere else. Gating works when the answer comes back in a minute, instead of whenever someone checks a channel. And when time runs out, the action does not run, and the saved record shows that it timed out.
Worth reading: NIST SP 800-61 on computer security incident handling.
Add it to your product. Your users never make a Pushary account or pay us.
FAQ
Questions, answered
Can we auto-approve high confidence detections and gate the rest?
Does this replace our on-call paging tool?
What does the incident record look like afterwards?
What if the analyst is mid-incident and misses it?
Put a person on the step that needs one.
Connect a user once, ask with one call, and run the action only on a yes. Every answer is saved.
Start free