TL;DR: Deep cloud and runtime telemetry are being used by agentic RADBots to investigate, prioritise, and triage security signals based on ground truth, according to RAD Security. The governance question is whether digital workers that can suggest and perform remediation steps are still being controlled as tools, or whether their runtime authority now needs identity and lifecycle treatment.
At a glance
What this is: RAD Security says its Inception membership is intended to accelerate agentic security workflows that turn telemetry into triage and remediation action.
Why it matters: For IAM teams, the relevant issue is not the partnership itself but the identity model behind digital workers that can act on security signals, which affects lifecycle, privilege, and accountability across NHI and autonomous programmes.
👉 Read RAD Security's announcement on joining NVIDIA Inception
Context
Agentic security operations are moving beyond alerting into decision support and execution, which changes how identity governance should treat the software that performs the work. When a system can investigate, prioritise, and trigger next steps from runtime telemetry, the key question becomes who or what is authorised to act, under what scope, and with what oversight.
RAD Security's announcement is about joining NVIDIA Inception, but the practitioner relevance sits elsewhere. The article describes RADBots as digital workers that can suggest and then perform remediation steps, which means security teams should read this through the lens of non-human identity governance, not startup marketing. The primary keyword here is agentic security operations, and the governance implication is that execution authority now matters as much as detection quality.
Key questions
Q: How should security teams govern AI systems that can both triage and remediate alerts?
A: Treat them as privileged non-human identities with explicit ownership, scoped permissions, and revocation paths. Separate recommendation rights from execution rights, and require audit trails for every action that changes production state. If the system can act, its access should be reviewed like any other high-risk identity, not left inside an operations workflow.
Q: Why do agentic security tools change identity governance requirements?
A: Because the risk is no longer only whether the tool detects accurately. The system can now choose actions, consume telemetry, and perform remediation, which creates a lifecycle and privilege problem. Identity teams need to govern who can approve those actions, what data can justify them, and how the system is removed when its role changes.
Q: What breaks when digital workers are treated as ordinary automation?
A: You lose ownership, review, and offboarding discipline for a system that can affect production security state. Ordinary automation assumes fixed behaviour and narrow impact, but a digital worker can operate across changing contexts and may accumulate access over time. That creates a gap between actual authority and the controls used to manage it.
Q: When should organisations restrict remediation authority in AI-driven security workflows?
A: Restrict it whenever the system can act on signals that are incomplete, noisy, or influenced by untrusted sources. If a workflow can change containment, create tickets, or modify access, those actions should be separated by approval, scope, or environment. The safest default is advisory first, execution second.
Technical breakdown
Agentic security operations and runtime decision loops
Agentic security operations differ from classic SOAR-style automation because the system is described as investigating signals, prioritising them, and then choosing next steps from ground truth in real time. That introduces a runtime decision loop, where the tool is not only following a fixed playbook but selecting actions based on changing context. In identity terms, that makes the actor behave more like an autonomous executor than a passive workflow. The important architectural distinction is between recommendation and execution. Once the system can move from analysis to action, its identity, access scope, and approval path need to be assessed as a governing control surface.
Practical implication: classify any system that can both recommend and execute remediation as a governed identity, not just a monitoring feature.
Deep cloud and runtime telemetry as the basis for trust
The article emphasises ground truth, which in security operations means the action engine depends on telemetry from cloud, workload, and runtime sources rather than static policy alone. That matters because agentic systems are only as reliable as the evidence they ingest. If the telemetry stream is incomplete, stale, or manipulated, the action layer can make confident but incorrect decisions. This is where identity and observability intersect: the system that consumes telemetry often gains implicit authority to change posture, isolate assets, or open tickets. In practice, the trust model must define which data sources justify action and which actions remain read-only.
Practical implication: map every automated response to a verified telemetry source and separate read-only analysis from write-capable execution.
Digital workers need lifecycle governance, not just model governance
When the article calls RADBots digital workers, the identity question becomes lifecycle management. A digital worker that can perform remediation needs onboarding, scope assignment, review, offboarding, and auditability in the same way other non-human identities do. That does not mean treating it like a human user, but it does mean applying governance that tracks what it can do, when it can do it, and who can revoke it. This is especially important when AI capability is framed as an operational accelerator, because operational accelerators tend to accumulate privilege faster than teams revisit ownership.
Practical implication: put agent identities into the same entitlement review and offboarding process used for other high-risk non-human identities.
NHI Mgmt Group analysis
Execution-capable security automation is a governance problem, not a tooling feature. Once a security system can do more than recommend remediation, it occupies a non-human identity role with real operational authority. That shifts the question from model quality to entitlement control, auditability, and revocation. The implication is that security operations teams must stop treating agent output as advisory by default when the system can actually act.
Ground truth does not eliminate identity risk, it changes where the risk sits. Telemetry-driven systems can make better decisions than static rules, but they also concentrate trust in the data-to-action pipeline. If the system can decide that telemetry is sufficient evidence to execute a response, the control failure moves upstream into who can influence the signals and downstream into who can authorize the response. Practitioners should view this as a runtime trust boundary, not simply a detection improvement.
Digital workers expose a lifecycle gap that most security programmes have not modelled. The article's language is useful because it reveals the governance assumption behind many AI deployments: that the thing doing the work is temporary, abstract, or subordinate enough to skip lifecycle management. That assumption fails when the actor can investigate, prioritise, and perform remediation steps independently. The implication is that non-human identities with action authority need the same offboarding certainty and review discipline as other privileged actors.
Naming the concept matters: agentic security operations create an identity blast radius. When a system can both interpret signals and carry out actions, every added integration expands the potential impact of a compromised model, poisoned telemetry source, or overbroad permission set. The blast radius is no longer limited to false positives or delayed triage. It extends into the operational environment the agent can touch. Practitioners should govern that blast radius as an access problem, not only an AI operations problem.
From our research:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
- That same survey found that only 13% of organisations feel extremely prepared for the reality of agentic AI, which shows how quickly governance is lagging capability.
- For the next step, compare this with OWASP Agentic AI Top 10 to map where runtime action, privilege, and trust boundaries fail.
What this signals
Agentic security operations will force identity teams to distinguish between recommendation systems and action systems. The governance model changes once a security worker can move from analysis to remediation without human re-entry. That means programme owners should prepare entitlement models, approval boundaries, and audit expectations for systems that behave like privileged identities rather than analytics tools.
With 70% of organisations granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the pattern is already clear: access is being expanded faster than governance is being redesigned.
The immediate forward signal is not that teams need more AI, but that they need more explicit control over what an AI system is allowed to do after it observes a signal. If remediation becomes machine-executed, lifecycle review and privilege scoping move from IAM hygiene to operational safety.
For practitioners
- Define whether the security worker can execute or only recommend Separate advisory workflows from write-capable workflows before granting the system access to containment, ticketing, or remediation functions. If it can trigger changes, treat it as a privileged non-human identity and document the approval boundary clearly.
- Inventory every telemetry source that can justify action Record which cloud, workload, and runtime signals feed decisions and which sources are trusted enough to trigger remediation. Revisit that list when data quality changes, because action authority should not outrun signal integrity.
- Add lifecycle controls for digital workers Create onboarding, ownership, review, and offboarding steps for any AI system that can perform security operations. Place those records in the same governance process used for other high-risk non-human identities.
- Limit remediation permissions to task-scoped access Grant only the minimum actions required for the specific response the system is allowed to perform. Use task-scoped permissions so a triage worker cannot drift into unrestricted operational control.
Key takeaways
- RAD Security's announcement matters because it frames security AI as an actor that can perform work, not just analyze it.
- The governance issue is not model accuracy alone, but the identity, privilege, and lifecycle controls behind action-capable digital workers.
- Practitioners should separate advisory automation from execution authority and manage agent identities with the same rigour as other privileged non-human identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic remediation flows can create tool-misuse and overreach risks. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Action-capable digital workers need scoped credentials and reviewable lifecycle. |
| NIST CSF 2.0 | PR.AC-4 | Privilege scoping and access governance are central when AI can perform remediation. |
Assign task-scoped access, review entitlements, and rotate or revoke credentials on role change.
Key terms
- Agentic Security Operations: Security operations in which software does more than analyse alerts and can also choose and perform response actions. The important shift is from recommendation to execution, which makes the system an operational actor that needs entitlement, oversight, and revocation controls.
- Digital Worker: A software-based actor that performs tasks normally handled by a human operator or analyst. In identity governance terms, a digital worker can hold access, trigger workflows, and affect production systems, so it needs ownership, review, and offboarding discipline.
- Runtime Trust Boundary: The point at which live data, signals, or context become sufficient evidence for a system to take action. For identity teams, this boundary defines when a tool stops being read-only and starts becoming a privileged executor.
- Agent Identity: The identity, access, and lifecycle profile assigned to an AI system that can act in an environment. It is not the same as a human account, but it still needs scoped permissions, accountability, and a clear path for disabling access.
What's in the full article
RAD Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How RADBots are described as digital workers across investigation, prioritisation, and triage flows
- The company-specific product context behind its AI workflow design and go-to-market positioning
- The NVIDIA Inception benefits RAD Security says will support product development and technical work
- The exact wording RAD Security uses to describe its telemetry-driven security workflow
👉 RAD Security's full post explains how it frames agentic RADBots, AI capability, and startup support.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2025-08-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org