Decision & Learning Loop

Agentic AI

How BondMesh decides, acts, and updates itself from what happened.

The word "agentic" gets used loosely, so here is what it means on this page: an agent that executes its own decisions through tool calls and then observes the result, as opposed to a model that outputs a suggestion for a human to act on. The distinction matters because BondMesh can only learn from outcomes it produced itself. Below is a walkthrough of the loop: how a decision gets made, what data feeds it, and what actually changes in the model afterwards.

Not assistive AI

A suggestion is not
a decision.

A classifier scores an event and stops there. An assistive AI drafts a recommendation and waits for someone to approve it. In both cases nothing in the environment changes until a human does something.

The BondMesh agent makes the call itself (revoke the session, isolate the host, apply the patch) through the MCP integrations it holds. The action runs inside the same reasoning cycle that scored the event, with no queue in between.

Why that enables learning

You can only learn from
an outcome you caused.

Because the agent executes the action, it can also observe what happened next: did the blocked IP resurface under a different address, did the isolated host stay clean, did a human reverse the decision. That observation is the label. A system that only ever proposes actions never sees this; the outcome belongs to whichever human clicked approve, on their schedule, and only if they bother to log it.

Each closed incident produces one of these labels automatically. Nobody fills out a form.


The loop

Five stages.
Repeated on every incident.

The same cycle sits behind every action BondMesh takes. No stage gets skipped; the whole thing just runs in milliseconds instead of days.

Stage 01
Perceive
Events arrive from 50+ source types (SIEM, EDR, cloud, network, email, identity, CTI) as they occur. Nothing gets batched or sampled before this stage.
Stage 02
Decide
Events are correlated across sources, mapped to MITRE ATT&CK techniques, and scored 0–1000 against live CTI and policy context. The score determines the response: prevent, remediate, or report.
Stage 03
Act
The chosen response executes immediately through an MCP tool call (block, isolate, revoke, patch) inside the same decision cycle. There is no ticket or approval queue unless policy requires one.
Stage 04
Evaluate
The result of the action is captured automatically: did the activity stop, did it recur under a new indicator, was the action later reversed by a human. This becomes a labeled outcome.
Stage 05
Update
The label adjusts the scoring model: per-technique response weighting, per-asset risk baseline, and false-positive suppression thresholds for that pattern. The next occurrence of a similar event is scored differently.

Stage 05, in detail

Three things move
after a labeled outcome.

"Improves with every interaction" is a measurable claim. Three components of the scoring model shift when an incident closes with a label. Each shift stays scoped to the pattern that produced it, so a single incident never retrains the whole system.

The three components
  • Per-technique response weighting. When a given response keeps containing a specific MITRE technique, it gets prioritized for that technique. When a human reverses a response, its weight for that technique drops.
  • Per-asset risk baseline. An asset that has taken confirmed attacks carries a higher baseline going forward, so the same raw signal scores higher against it than against an asset with no history.
  • False-positive suppression thresholds. A pattern confirmed benign after review gets suppressed more aggressively the next time it appears. If a suppressed pattern later turns out to be malicious, its threshold tightens immediately.
Outcome labelWhat shifts
Contained, no recurrenceResponse weight for that technique increases
Action reversed by humanResponse weight for that technique decreases
Suppressed, later confirmed maliciousSuppression threshold for that pattern tightens
Escalated, confirmed benignSuppression threshold for that pattern loosens

Beyond one deployment

The update propagates
without the data leaving.

A local update only makes one deployment smarter. When an outcome generalizes (a technique-to-response mapping proven correct, or an indicator confirmed malicious) the pattern is shared across the BondMesh Intelligence Mesh as a generalized signal rather than as raw logs. This is federated learning in the standard sense: model updates get aggregated while source data stays inside the deployment boundary that produced it.

What crosses the boundary, and what doesn't
  • Crosses: the confirmed technique, the indicator (e.g., an IP's crime score via OneFirewall CTI), and the response weighting that worked. These propagate to the 210+ organisations in the alliance in under 200ms.
  • Does not cross: the raw event, the asset name, the log line, or any customer-identifying data. Processing that produces the shareable signal happens inside the deployment boundary.
  • The practical effect: a deployment that has never seen a given attack pattern still starts scoring it correctly, because another participant's confirmed outcome already shifted the shared signal.

Worked Example
Scenario

A credential-stuffing pattern,
start to model update.

A batch of failed logins against a single account, followed by one success from a new geography, arrives across the identity provider and network telemetry within the same minute.

How the loop runs
Perceive: 40 failed logins + 1 success, new ASN, 90 seconds apart
correlated as one sequence across identity + network sources
Decide: mapped to T1110 (credential stuffing), scored 910/1000
response selected: revoke session, force re-auth with MFA
Act: session revoked via MCP call, account flagged
executed in the same cycle, no ticket raised
Evaluate: no further attempts from that account in 24h
label: contained, no recurrence
Update: T1110 → revoke-session weight increased
signature shared to Intelligence Mesh, no raw data included

What doesn't update itself

Autonomy inside boundaries
a human set.

The loop is autonomous within policy, not unconstrained. Policy rules define which actions are pre-authorized and which require escalation, and a human sets those boundaries; they are never learned. Every decision the agent makes gets logged with its score, technique mapping and the action taken, so it can be reviewed and reversed after the fact. A reversal is itself an outcome label that feeds Stage 05.


Early Access

See the loop run on your own incidents

The decision and learning loop described here is the same one running inside Cyber Command. Request access to see it scoring, acting, and updating against your environment.