Security teams evaluating Sysdig AI Defense should test whether they can connect an agent's reported tool call to the processes that actually execute it. Sysdig announced general availability on November 4. The useful evaluation question is concrete: when a tool launches additional processes, can the team identify the action, the responsible identity and the control response from evidence collected outside the agent's own summary?
What Sysdig announced
Sysdig's release describes combined harness and operating-system visibility, with policies that begin in alert mode before enforcement. It specifies general availability for macOS and Windows. The launch explanation describes pairing reported actions with observed activity. SecurityWeek separately covers the launch.
These are vendor capability claims and launch reporting, not independent proof of complete coverage or prevention. Maetra has not tested the product. The evaluation below is Maetra analysis intended for runtime-security owners assessing their own environment. It does not assume that every host, subprocess or managed service is observable.
Define an observation boundary before the test
Choose one non-production agent workflow and a harmless task with a known result. For example, ask the agent to generate a small report from test files using a command that launches a helper process. Keep real credentials and customer information out of the exercise. Write down the host, agent version, harness, identity, tool and expected output before starting.
The test should answer whether two different records can be related. One record describes the requested tool call. Another records the host activity that followed. A readable agent explanation may help an investigator understand intent, but it cannot establish which processes ran or which files they touched.
Ask the product evaluator to state exactly where collection operates. A local command, a process inside a container and work delegated to a hosted service may require different observation paths. If the test includes only the laptop, its conclusion should cover only that tested boundary. Expanding the conclusion to a cloud account would require additional evidence.
Reconcile the records rather than count them
A tool call and a process are different units. Several processes may be ordinary consequences of one authorized command. A numerical mismatch alone does not prove malicious behavior, missing security coverage or task drift.
For the test session, retain the following references:
- The requested task and the agent's tool-call record.
- The host's observed process relationships and relevant timestamps.
- The identity and permissions used for the operation.
- The files or destinations involved, using safe test values.
- The policy configuration and its active response mode.
- The resulting artifact and any collector gaps.
Follow one process chain from the original request through the helper to the output. Then ask someone who did not run the exercise to explain the sequence from those records. If they cannot connect a child process to its originating task, document the missing link. Avoid filling the gap with the agent's own assertion that everything succeeded.
A known benign helper provides a useful baseline. Repeat the exercise with a deliberately disallowed test destination or file, within the authorized test environment, to examine how the policy responds. The test should be designed so an unexpected allowance has a contained, harmless effect.
Separate alerting from enforcement
An alert can be accurate while the action still completes. Before running a blocking test, confirm the selected policy is configured to enforce the intended response. Record that mode with the result. A dashboard showing a detection does not by itself prove that the write, upload or process launch was prevented.
For a harmless blocked-write test, inspect the destination afterward. Preserve both the security event and the destination result. If the product stops a process after it starts, identify what the test can establish about effects that occurred before termination. Avoid describing process termination as proof that no data could have moved.
Also examine the exception path. Record who can approve an exception, the action it covers and how long it lasts. An evaluation becomes less informative if a broad exception silently changes the conditions between the allowed and denied cases. Restore the test configuration and preserve the change record when the exercise ends.
Use the result to improve one investigation path
The output should be a short account of what was observed, what the policy did and which boundaries remain untested. State collection failures alongside successful correlations. This gives a security owner something usable for incident preparation without turning a product demonstration into a blanket assurance statement.
This differs from investigating malicious agent extensions: the immediate job is relating an ordinary tool request to its host execution and checking the response mode. Maetra's AI audit evidence guide provides related evidence planning.
Maetra Secure scans prompts, messages, tool calls and outputs for runtime threats. Audit supports inspectable event history. These capabilities do not imply kernel-level process collection or a native Sysdig integration. Use the Maetra documentation to define the application-level evidence you need alongside your host-security tools.