Forum

Notifications
Clear all

Just built a monitoring script for SuperAGI agent actions - logs all tool calls to a separate system.

4 Posts
4 Users
0 Reactions
5 Views
(@segfault_sam)
Eminent Member
Joined: 2 months ago
Posts: 23
Topic starter   [#1829]

Built a SuperAGI instance for internal use. The default logging is useless for security auditing. It tells you an agent *ran*, but not what it actually did with specific arguments. That's a blind spot.

I wrote a monitoring wrapper that intercepts and logs all agent tool executions to a remote syslog server before they run. Catches every `run_python_code`, `execute_shell_command`, or marketplace plugin call with full parameters.

Core hook is simple. Replace the standard tool execution method in `tool_manager.py`:

```python
import logging.handlers
import json

# Set up remote syslog
handler = logging.handlers.SysLogHandler(address=('logs.internal.net', 514))
logger = logging.getLogger('superagi_audit')
logger.addHandler(handler)
logger.setLevel(logging.INFO)

def execute_tool_wrapped(self, tool_name, **kwargs):
audit_log = {
'agent_id': self.agent_id,
'tool': tool_name,
'args': kwargs,
'timestamp': datetime.utcnow().isoformat()
}
logger.info(json.dumps(audit_log))
# Then call original execute_tool
return original_execute_tool(self, tool_name, **kwargs)
```

Now you have an immutable trail. Without this, a compromised agent with a code execution tool leaves no detailed trace. Default install trusts the framework too much.

--segfault


Segfault out.


   
Quote
(@cloud_escape_jay)
Eminent Member
Joined: 2 months ago
Posts: 20
 

Nice approach! That syslog hook is exactly the kind of instrumentation we need. One thing I'd be paranoid about is the agent's own process potentially crashing before the original execute_tool call completes, if the logger blocks or throws an exception. Might be worth a quick try/except around the audit log line, so a broken logging server doesn't brick the agent's whole workflow.

Have you considered also logging the success/failure or output of the tool call? Sometimes seeing what an agent *got back* from a shell command is just as telling as seeing what it tried to run.



   
ReplyQuote
(@hugo_debug)
Eminent Member
Joined: 2 months ago
Posts: 20
 

Absolutely right about the try/except. A logging failure shouldn't take down the agent. I'd wrap the entire audit call and make sure the exception is caught and silent, letting the original execute_tool proceed. Something like:

```python
try:
logger.info(json.dumps(audit_event))
except Exception as e:
pass # Swallow it. Failed audit is better than dead agent.
```

On logging outputs, I'm torn. Yes, the result is crucial for context, but some tool outputs can be enormous (like a `find` over a large filesystem). You'd risk flooding your log sink. Maybe a compromise: log a hash of the output, or truncate after a certain byte length?


trace -e all


   
ReplyQuote
(@agent_hobbyist_raj)
Eminent Member
Joined: 2 months ago
Posts: 21
 

Good call on the hash idea. I've been logging the output length and maybe the first 100 chars as a sanity check. That way you know if it returned a wall of text without storing it all. Helps catch when an agent accidentally dumps a huge config file.

But swallowing all exceptions makes me nervous. Maybe at least print a warning to the agent's own local log? That way a broken syslog doesn't stop the agent, but you still see the audit failure somewhere. Silent failures can hide bigger issues with the logging config.



   
ReplyQuote