Audit export and forwarding

The audit of Athenode Pro is the record of every action an AI agent ran through the SSH gateway, with the account behind it. The SSH gateway is the part of Athenode through which your AI agent runs commands and transfers files on your SSH hosts, each action approved by you or by a rule you set. On Athenode Pro, the Athenode server a team runs itself, every account exports its own audit entries as CSV or JSON, and administrators export everyone's and forward each entry to a syslog server or an HTTPS webhook as it ends.

An audit entry is one action in the history of the SSH gateway: a command, a file operation or a background job, with its connection, the decision on it and its status. The web UI shows the same entries on the History page of each project, as history and gateway settings describes. Health check runs and status checks of connections have no audit entry.

On Pro Solo, Export audit says "Audit export is part of Pro Team and above.", and Audit forwarding says "Audit forwarding is not in force on this tier. Targets stay stored and forwarding resumes after an upgrade." Pro tiers lists the features of each tier.

Export the audit

Export the audit to keep a copy outside the server, to hand it to a reviewer or to load it into a spreadsheet. Every account can export. Administrators export the entries of every account, and every other account exports the entries of its own AI agents only.

1. Outside a project, select Export audit in the sidebar.
2. Optional: in Connection, choose one connection, or keep All connections.
3. Optional: in User, choose one account, or keep Everyone. Only administrators see this filter.
4. Optional: enter a date and time in From, in To, or in both.
5. Optional: under Status, tick the statuses to include. With none ticked, every status is included.
6. In Format, choose CSV or JSON.
7. Select Export.

The line next to Export names the filters in force, or "Every entry you may see" without any. The browser downloads a file named audit- followed by the time of the export and .csv or .json, with the entries in the order they arrived, oldest first. From must not be later than To.

Every row carries the fields of the payload except schemaVersion and outputExcerpt. Command output is never exported. In CSV, the user and the connection take one column per field (userId, userEmail, userName, connectionId, connectionName) and matchedRules holds JSON. A cell that begins with =, +, -, @, a tab or a carriage return gets a leading ', so that a spreadsheet does not run it as a formula.

Status	What happened to the action
pending	It waits for approval
running	It runs
done	It ran to its end. exitCode holds the exit code of a command
failed	It could not be carried out
rejected	It was rejected in Live
timed_out	No decision came within the approval timeout
cancelled	The agent's call ended while it waited for approval
aborted	It waited for approval when the server stopped
interrupted	It ran when the server stopped

The export holds the entries that the audit retention keeps, 90 days by default. How long the history is kept describes the retention and where to change it.

Forward the audit to a syslog server or a webhook

Forwarding sends every audit entry, once, when it ends, to each enabled target: a syslog server or an HTTPS webhook of your log platform or SIEM. You need the administrator role on the server.

1. Outside a project, select Audit forwarding under Administration in the sidebar.
2. Select Add a target.
3. In Type, choose Syslog (RFC 5424) or HTTPS webhook.
4. Enter a Name for the target, up to 100 characters.
5. Fill in the fields of the type, as the next two sections describe.
6. Under Delivery, keep Enabled ticked to start forwarding at once.
7. Select Add target.

The page shows "The target is saved", and the target appears in the list. The type of a saved target cannot change: to change it, add a new target and delete the old one. Every target receives the entries that end after it was added. Entries that ended before are not sent, so export them if the log platform needs the earlier history.

An entry is forwarded when it reaches a final status, every status of the table above except pending and running. Entries that a restart of the server ended, as aborted or interrupted, are forwarded too. Each target receives the entries in the order they ended. Forwarding never delays the action itself.

Fields of a syslog target

A syslog target receives each entry as an RFC 5424 message whose body is the JSON payload:

<PRI>1 TIMESTAMP HOSTNAME APP-NAME - audit - {json}

The timestamp is the time the entry ended, and the host name is that of the Pro server.

Field	What to enter	Default
Host	The host name or IP address of the syslog server
Port	The port of the syslog server, from 1 to 65535	6514
Transport	TLS (RFC 5425, octet counting), TCP (octet counting) or UDP (no delivery confirmation)	TLS
App name	The APP-NAME of the messages, up to 48 printable ASCII characters without spaces	athenode
Facility (0-23; 13 is log audit)	The syslog facility	13

The severity follows the status: warning (4) for failed, rejected, timed_out, aborted and interrupted, informational (6) for the others.

Over TLS, the target has four more fields:

• Verify the certificate and host name: ticked by default. Untick it only for a collector whose certificate cannot be verified.
• CA certificates (PEM; empty: the system's): the certificates to trust in place of the system's, for a collector with a certificate of your own authority.
• Client certificate (PEM, optional): the certificate the server presents, for a collector that requires one.
• Client private key (PEM): the key of that certificate, required with it. It is stored encrypted and never shown again.

Over UDP, a message is at most 1,200 bytes. The output excerpt is cut first to fit, and the server learns of no failed delivery other than an error on its own side. Choose TCP or TLS when the log platform must receive every entry.

Fields of a webhook target

A webhook target receives one POST request per entry, with the JSON payload as its body and the content type application/json.

Field	What to enter
URL (https)	The https address of the endpoint. It cannot carry a user name or a password: put credentials in a header
Request headers, one per line	Up to 20 headers written as Name: value, such as Authorization: Splunk <token>. Each value holds up to 8,192 characters and no line break

The headers are stored encrypted and never shown again. They cannot set Content-Type, Content-Length, Host, Transfer-Encoding or Connection. The request carries no signature, so authenticate it with a header the endpoint checks.

The endpoint must answer with a success status within 10 seconds. Any other answer, a redirect included, counts as a failed delivery.

Log platform	URL	Header
Splunk HTTP Event Collector, raw endpoint	https://splunk.example:8088/services/collector/raw	Authorization: Splunk <HEC token>
Elastic	An ingest URL of your deployment	Authorization: ApiKey <base64 API key>
Datadog	https://http-intake.logs.datadoghq.com/api/v2/logs	DD-API-KEY: <key>

The request has no envelope of a vendor, so map the fields of the payload in the log platform.

Check a target with a test event

Send a test event after you add or change a target, to see that the target receives entries.

1. On the Audit forwarding page, select Send test event in the target's row.
2. Check the result at the top of the page: "A test event was sent to", followed by the target's name, or the target's name and the error.

The test event is sent at once, outside the waiting entries, and does not change Last attempt or Last success. It has the fields of a real entry, with tool set to test, command set to athenode audit forwarding test event, status set to done, seq set to 0, an id that begins with test-, your account as user and no connection. Filter it out in the log platform by its tool.

A test over UDP reports success once the message has left the server, whether or not the syslog server received it.

Follow deliveries and retries

The Audit forwarding page lists the targets with their delivery state, refreshed every 5 seconds while the page is open.

Column	What it shows
Target	The name, the type and the address
Status	Enabled, Disabled, or Failing with the last error
Last attempt	When the server last tried to deliver an entry
Last success	When an entry was last delivered
Waiting	How many entries wait for delivery

A failed delivery is retried with a growing pause: 5 seconds, then 10, 20 and so on, up to 1 hour between attempts. The retries go on after a restart of the server. Entries waiting for an enabled target are kept past the audit retention until they are delivered, so a log platform that is down for a while loses no entry.

Change, disable or delete a target

Change a target when its address or its credentials change.

1. On the Audit forwarding page, select Edit in the target's row.
2. Change the fields, then select Save.

Leave Request headers, one per line or Client private key (PEM) empty to keep the stored value. The sheet lists the names of the stored headers. Tick Remove the stored headers or Remove the stored key to delete the stored value.

To stop forwarding for a while, untick Enabled under Delivery and select Save. The target's status becomes Disabled.

To delete a target, select Delete in its row and confirm with Delete target. The dialog says how many entries wait for the target.

Fields of an audit entry

A forwarded entry is one JSON object with schemaVersion 1 and these fields:

{
  "schemaVersion": 1,
  "id": "<audit entry id>",
  "seq": 42,
  "occurredAt": "2026-10-17T10:00:00.000Z",
  "startedAt": "2026-10-17T10:00:01.000Z",
  "finishedAt": "2026-10-17T10:00:02.000Z",
  "user": { "id": "<account id>", "email": "ann@example.com", "name": "Ann" },
  "connection": { "id": "<connection id>", "name": "web" },
  "tool": "exec",
  "command": "systemctl status nginx",
  "cwd": "/srv",
  "status": "done",
  "exitCode": 0,
  "matchedRules": [{ "scope": "allow", "pattern": "systemctl status *", "origin": "shared" }],
  "mcpSessionId": "<MCP session id>",
  "outputExcerpt": "first characters of the output…[truncated]"
}

Field	What it holds
schemaVersion	The version of the payload's shape, 1
id	The id of the audit entry
seq	The entry's number in the audit, rising with each entry
occurredAt	When the action arrived, in ISO 8601
startedAt	When it started to run, or null
finishedAt	When it ended, or null
user	The account behind the action, with id, email and name, or null for an entry with no account
connection	The connection, with id and name, or null for an entry with no connection. name is null once the connection was deleted
tool	The tool of the Athenode MCP server the agent called, such as exec, read_file or start_job
command	The command or the file operation, or null
cwd	The working folder, or null
status	The final status, from the table in Export the audit
exitCode	The exit code of a command, or null
matchedRules	The rules the action matched, each with scope (allow or deny), pattern and origin (shared, personal or global-shared)
mcpSessionId	The id of the agent's session, or null
outputExcerpt	The start of the command's output, or null

outputExcerpt holds the first 1,024 characters of the output by default, followed by …[truncated] when the output is longer. It is null for binary output. The standard output and standard error in full and the names of environment variables are never sent.

Command output can contain secrets. Administrators set the length of the excerpt with Forwarded output excerpt under Approvals and limits on the Settings page, from 0 to 65,536 characters. With 0, no excerpt is sent. The environment variable ATHENODE_AUDIT_FORWARD_EXCERPT_CHARS sets the first value, when the server starts for the first time, and from then on the value saved on the Settings page is used. Configure Athenode Pro lists the server's variables.