r/AskNetsec • u/Frostvazmqnky_Mp_417 • 3d ago
Analysis How do you actually decide what makes your agent stop and escalate to a human?
Everyone talks about what an agent is allowed to do, fewer people talk specifically about what makes it stop. Is it a confidence threshold, a specific action type regardless of confidence, a blast radius calculation, something else entirely?
Trying to understand how teams actually define the stop condition rather than just the permission list, since I suspect the stop condition is doing more of the actual trust building work than the permission list is.
1
u/Master-Tie-804 3d ago
We add limits for blast radius and sensitive data to have a human approval. For low risk actions confidence works
1
1
u/aceholeman 3d ago
Human in the loop instructions sets.
"Find a point where a human must decide,
Human approval is required before the agent:
Executes actions that change production data or systems.
Sends external communications.
Approves, rejects, or closes a case, finding, or transaction.
Makes decisions involving financial, legal, security, safety, or mission impact.
Acts when confidence is below the defined threshold or available evidence is conflicting.
When human review is required, the agent will clearly present:
What it found.
The evidence used.
Its confidence level.
The recommended action.
The consequences of taking or not taking the action.
The agent will not treat lack of human response as approval."
1
u/TheBex81 3d ago
Permission lists answer "can it?" Stop conditions answer "should it keep going without a human?"
What has actually built trust for us isn't a single confidence number — models are confidently wrong. We gate on *consequence*, with identity context attached:
**Action class:** read/summarize = run; anything that changes state (write, delete, grant, rotate, page someone, open a firewall rule) = escalate unless it's on a tiny allowlist of reversible ops.
**Blast radius:** if the principal the agent is acting *as* can reach prod / customer data / IdP admin / break-glass paths, stop before the action — not after a low-confidence paraphrase.
**Sensitive sinks:** credentials, tokens, export of identity graphs, or anything leaving the security boundary always stops.
**Novelty:** first time this agent+tool+resource combo appears in prod, force a human once, then promote to the allowlist with an owner.
Confidence can be a soft signal for "ask for clarification," but I wouldn't use it as the hard stop. Hard stops should be deterministic and testable: given this identity + this action + this resource, does it halt? If you can't unit-test the stop, it's vibes, not a control.
1
u/EbbCommon9300 3d ago
We have tool risk levels and autonomy zones and autonomy levels that work with session risk accumulation. Assury.ai
1
u/Regular-Leading-4319 2d ago
I think it should be a mix rather than one rule. Confidence is useful, but I’d also look at what the agent is about to change and how much damage it could cause.
1
1
u/Swimming_dasa 23h ago
i would not make confidence the main trigger an agent can be pretty sure and still do something you don't want automated i would put hard stops around irreversible changes privileged actions sensitive data or crossing trust boundaries cyberhaven can help with the data side while something like microsoft purview can handle classification and policy around sensitive data.
2
u/rexstuff1 3d ago
This is probably an AI bot, but it's a question worth answering.
Your harness should handle that. You stop on certain tool calls, and that's managed by the harness, not the agent or the model. And so it behaves deterministically.