AI can help attackers move from discovery to exploitation faster. It can also help defenders test their own systems more often. For a security leader, the practical question is where continuous testing ends and live investigation begins.
What continuous exposure testing does
On September 22, Palo Alto Networks announced Unit 42 Continuous Frontier AI Defense. Its published description focuses on discovering and validating exposures in changing environments and recommending code-level fixes or virtual patches. That is a useful response to the limits of periodic assessments. Read Unit 42's description.
The operational distinction matters: an assessment can show a plausible attack path before an adversary uses it. A defender also needs to know whether a real identity or workload is already crossing a boundary, accessing unusual data or moving it to an unapproved destination. One question is, “What could be exploited?” Another is, “What is happening now, under whose authority, and with what result?”
What runtime monitoring adds
For AI agents, OWASP recommends scoped tool permissions, approval for sensitive actions, and monitoring of decisions, tool calls and outcomes. Its guidance specifically calls out unusual tool use, repeated approval bypass attempts and elevated privileges. Read OWASP's AI Agent Security Cheat Sheet.
Google Cloud likewise describes runtime observation of data paths and agent actions as a complement to checks made before deployment. Its guidance says active monitoring and centralized logs are needed to trace and restrict data movement after an agent is running. Read Google's vulnerability-management blueprint.
These sources describe controls and approaches, not a claim that any one product can see everything. Network data may reveal destinations and timing while leaving encrypted content opaque. Application, identity, cloud and agent-tool logs can show other parts of the sequence. An investigation should connect the evidence, retain uncertainty and avoid treating “AI-generated” as a reliable fingerprint of malicious activity.
A practical investigation sequence
Suppose an agent or service account reads records outside its normal task, creates a credential and sends data to an unfamiliar endpoint. This is a hypothetical example, not a reported DGM customer incident.
- Establish authority: Identify the account or agent, its owner, permitted task, resources and time window.
- Connect activity: Correlate application actions, network connections, tool calls and identity changes in time order.
- Assess likely intent: Consider legitimate explanations alongside reconnaissance, unauthorized access and data theft. Show the evidence behind the assessment.
- Contain with control: Apply a response within the customer's approval and rollback process.
- Verify: Retest the original path and check that legitimate activity still works. Preserve the result as evidence.
The last step deserves attention. Closing an alert or blocking one connection does not establish that a credential was revoked, an alternate path was closed or a patch actually fixed the weakness. See our verified-remediation method.
How DGM Intent approaches the problem
DGM Intent is in beta testing. Its implemented investigation workflow connects available evidence into episodes, presents likely-intent hypotheses with competing explanations, and lets an analyst review the underlying records. The initial business proposition is a scoped, passive Exposure Baseline for an internet-facing API estate. The synthetic demo includes network, application, database and agent examples; those examples are not a claim of customer source coverage or independently measured detection effectiveness. Explore the beta approach.
Continuous exposure testing helps find a possible door. DGM Intent's beta investigation asks what the permitted evidence shows about activity near it, and what remains unknown. Protection, repair and verification paths are being exercised in controlled labs, not offered here as proven production remediation. Consequential actions would remain under customer authority. Read our trust principles.
If your team is evaluating both AI-driven testing and live defense, map the evidence available from your applications, networks, identities and agents. Identify who may authorize a response and what proof would show that a fix worked. Explore DGM Intent and apply for business early access. Beta access is subject to availability and suitability; joining the waitlist does not activate protection.