Introducing Signal Analytics: a multi-agent AI system that reasons above existing security telemetry to continuously assess security posture by assessing security control effectiveness from observed behavior and control evidence
In one environment, 96 command lines across seven administrative hosts passed plaintext passwords through PowerShell, SSH, and Bash automation over 15 days.
These commands didn’t need to be malicious to be a problem. They were routine administration, and secret management wasn’t configured for any of it. Credentials passed as command-line arguments end up in process listings, command histories, and logs, where anyone with access to those can read them.
The question wasn’t whether an attacker had run a suspicious command. It was why routine administration handled credentials this way at all.
That distinction is what led us to rethink how we use security telemetry.
Most security analysis is organized around identifying threats: is this activity malicious, and does someone need to act on it? It's an essential question, but not the only one the same telemetry can answer.
Activity that doesn't warrant an investigation can still reveal how an environment operates. Across identities, systems, and time, it can expose practices that have drifted, controls that are insufficient, and risks that were never accounted for.
Security teams have invested heavily in tools that record activity, detect threats, and identify exposures. But understanding what all that evidence reveals about the security architecture, the controls and boundaries meant to protect the environment, is a different kind of analysis.
We built Netenrich Signal Analytics around that second question: what does the environment's behavior reveal about its security posture?
Introducing Netenrich Signal Analytics, a new product within the Resolution Intelligence Cloud™. It uses multi-agent AI to continuously assess security control effectiveness by connecting observed behaviors, control evidence, and environmental context—revealing where protections are insufficient, have drifted, or are holding, and what that means for the organisation's security posture.
The distinction becomes clearer when we examine identity activity. A denied sign-in from an anonymizing source can be assessed as an individual event. Across the same environment, additional observations about allowed access and the policies governing it raise a different question: what do those activities reveal about access controls?
The event-oriented question is whether an attempt was suspicious or successful. The environment-oriented question is whether the observed activity, read alongside policy evidence, reveals a protection gap. That second answer requires connecting observations rather than merely reclassifying an event.
Most security AI is aimed at making alert investigation faster. That work is valuable, but it is not the whole analytical problem.
Signal Analytics is built for the reasoning above the alert. It is the kind of security architecture assessment analysis a senior security architect would perform. It is the analysis a senior security architect would do: connecting signals across systems and time, examining the controls behind them, and determining what needs to change.
The challenge is doing that across thousands of signals, multiple systems, and weeks of changing activity. Signal Analytics makes that analysis repeatable, every week, without requiring a team to reconstruct the evidence each time.
It starts with observations: security activity and control evidence tied to specific identities, hosts, workloads, and resources. Across those observations it derives behaviors: the recurring access paths, privileged actions, and operating practices that no single event explains. It then evaluates those behaviors alongside control evidence and environmental context to determine what they reveal about posture: where governance has drifted, where controls are insufficient or absent, and where controls are demonstrably holding.
This is where multi-agent architecture comes in. Rather than treating each signal as an isolated event, specialized agents work across observations, behaviors, control evidence, and environmental context to build a connected understanding of posture.
The result isn't another alert about a command containing a password. It's a posture finding that identifies the underlying credential-handling practice, the systems affected, and the control that needs attention. The following separate Redis example shows how that conclusion appears in Standing Posture.
In one environment, an engineer passed a plaintext Redis password as a Python process argument and bulk-queried the datastore within a day. Signal Analytics surfaced the associated control gap and connected it to the supporting activity. The screens below show the finding and the evidence behind it.
Standing Posture in Signal Analytics. The finding is named as the control to fix, with its scope, the critical assets it touches, and the recommended change.
Every posture finding can be opened to its evidence: the identities involved, the systems affected, the actions taken, and when. The point isn’t just to present a conclusion. It’s to make the reasoning behind it inspectable.
The same finding, opened to its proof: the activity, entities, and evidence it was derived from.
In one environment, IPs associated with VPN exit nodes and residential proxy networks repeatedly attempted sign-ins against ten employee accounts over seven days. Across the same period, 562 sign-ins from anonymizing infrastructure were allowed. Conditional Access was doing exactly what it had been configured to do. The configuration simply had no policy for anonymizer or residential-proxy risk.
The two observations don’t establish that the attempted sign-ins succeeded. Together, they establish something more useful: the environment was under active pressure from anonymizing infrastructure, and a restriction that should have existed did not.
The same pattern appears at the application edge. In another environment, 71 Log4j, XXE, and related payloads reached the front doors of 35 public-facing services over 46 days. Reaching a service is not the same as exploiting it. But a web application firewall was in place and running, with no rule coverage for the class of payload that kept arriving. The answer wasn’t a new tool. It was getting the protection the existing one could already provide.
Every organization has an offboarding process, and every auditor checks that it exists. In one environment, 10 identities that had already been deprovisioned still showed mail activity: 26 email transactions over 46 days.
That doesn’t by itself mean former employees kept interactive access. The activity could come from delegated access or automated systems. Either way, something the offboarding process was meant to shut down was still operating. Mailbox disablement wasn’t happening as part of deprovisioning, and no alert would have said so, because sending email isn’t suspicious.
Drift usually looks like this. A control is deployed in report-only mode and never enforced. Self-service settings let administrators disable their own MFA. An offboarding step quietly stops happening. Nobody decides to weaken the posture. It erodes through practice, and behavior is where it shows first.
The plaintext passwords this piece opened with are the third kind. Nobody decided credentials should travel through process arguments, and nobody decided they shouldn’t. The practice grew out of getting work done, and it was visible only in how the environment behaved. These are often the gaps that matter most, precisely because no one ever thought to check for them.
Identifying a gap is only part of understanding posture. Two environments can share the same missing control, yet differ in how the weakness is exercised, what depends on it, and how safely it can be fixed. Observed behavior gives the configuration finding its operational relevance.
Configuration benchmarks remain essential. CIS, NIST, and vendor guidance identify the controls that should exist, and a scanner will correctly report every setting that fails a check.
But a configuration finding and its relevance are not the same thing.
Consider an AWS root account with active access keys. A scanner will flag the keys, and it will flag them the same way whether they haven’t been touched in a year or are used every day.
In one environment, telemetry showed repeated API activity using root credentials from the same source over multiple days. Any single call could have looked routine. Across time, it became clear that root was not reserved for emergency recovery. It had become an operational identity.
The finding moved from “root access keys exist” to “root access keys exist and root is being used to run the environment.” The configuration hadn’t changed. The understanding of the posture had.
That changes the response. Another alert for root API calls doesn’t fix it. The fix is to move routine work to scoped identities, use short-lived access with controlled elevation, and eliminate standing root keys. The aim is to change the practice that made the risky behavior normal.
Configuration tells you what is possible or permitted. Behavior tells you what is being exercised. Signal Analytics brings the two together, along with control evidence, context, and history, so that a posture finding explains not just what is wrong but why it matters in this environment, now.
That relevance is not always a reason to escalate. The same behavioral perspective can also show where controls are successfully resisting observed pressure.
Behavior also shows where defenses are working.
In one environment, a distributed password-spray campaign generated 315 attempts against 31 users from 249 IP addresses over seven days. Every attempt was denied or risk-blocked. A detection view rightly identifies the campaign. The environment view adds what matters for posture: the access controls were tested, and they held.
That is evidence of security control effectiveness, too. Security teams need to know where controls are missing, and also where they are demonstrably working, so they know where not to spend more.
A single observation tells us how a control performed at a moment in time. To understand posture, we also need to know whether that result persists, changes, or reflects an accepted operating practice.
Environments change. Teams find shortcuts, temporary exceptions become permanent, and practices outlive their purpose.
A posture gap shouldn’t be rediscovered from scratch every week. Signal Analytics carries each gap’s history forward: when it first appeared, whether it persists or closes, and whether its scope changes. A gap seen yesterday is different from one that has persisted for six weeks.
Organizational context matters as much as history. A behavior that signals a gap in one environment may be an understood, accepted practice in another. Signal Analytics takes that context into account, so accepted practices aren’t flagged as new every week. Over time, it holds the institutional knowledge that usually lives in a few people’s heads.
You can test this idea without changing tools. Take an alert your SOC closed as routine last week and ask four questions:
If answering means moving between your SIEM, posture tool, identity console, and cloud console and reconciling the views by hand, that reconciliation is a substantial piece of security work, and it usually goes undone.
Signal Analytics brings multi-agent reasoning to that work continuously. It connects observations across systems, derives behaviors from evidence, identifies posture gaps in their environmental context, and carries that understanding forward over time.
Posture comes from your behavior. A checklist tells you what should be protected. Behavior tells you where that protection is being tested.