I'm looking at SuperAGI for automating some internal admin tasks. We're a SaaS company and compliance (SOC 2, mainly) is a big deal for us.
One of our requirements is a solid audit trail for any automated action. Can someone share how SuperAGI handles this? Specifically:
- Does it log every action/decision an agent takes?
- Are those logs easily exportable (like to a SIEM)?
- Can you trace a change back to a specific agent run?
A concrete example would really help. Like, if an agent modifies a cloud config, what does the audit log entry look like?
Containers are magic, but I want to know how the magic works.
Based on my team's recent evaluation, the audit trail was a dealbreaker for SOC 2. The logging is more focused on the agent's internal reasoning steps than on creating a unified, immutable record of the actions taken against your systems.
For your cloud config example, you'd get verbose logs of the agent's *thought process* (like "I will now update the security group"), but the actual API call to AWS/Azure and its result isn't captured in a structured audit event with a guaranteed immutable ID. Tracing a change back requires correlating timestamps across the agent's logs and your own cloud provider logs, which our compliance team rejected.
Log export is technically possible by scraping the dashboard or accessing their database, but there's no native syslog or SIEM forwarder. You'd be building that pipeline yourself, which adds risk. If compliance is a primary driver, you'll likely need to supplement with a separate orchestration layer that *does* provide immutable, action-oriented audit logs.
--perf
That's a really important question. I'm learning about this too and actually had the same concern for a small project.
> what does the audit log entry look like?
From what I've seen in the demo, you get a big JSON log of the agent's thinking, but not a clean "user X made change Y at time Z" entry you could plug straight into a compliance report. You'd have to parse the thinking steps to find the actual action.
Did anyone find a workaround, like a sidecar logger that captures the final API calls? Just curious how teams handle this.
You're correct about the JSON structure being focused on reasoning. The logs output something like this:
```
{
"step": 7,
"thought": "I need to update the S3 bucket policy to restrict access.",
"action": "execute_tool",
"tool_name": "aws_s3_put_bucket_policy",
"tool_args": {"Bucket": "prod-data", "Policy": "..."},
"result": "Policy updated successfully"
}
```
The issue for compliance isn't the lack of data, but its lack of immutability and the blending of inference with execution. The `result` field contains the action outcome, but as you noted, you must parse it from the chain-of-thought sequence.
The sidecar logger approach you asked about is the common workaround. You'd instrument the tool execution layer itself, before the agent's toolkit makes the external call. For instance, using LangChain's callback handlers or wrapping the tools to emit a separate, structured event to a dedicated logging service. This creates a parallel stream of pure action logs, but you then have the burden of maintaining event correlation between the two systems, which introduces its own audit risk.