TASIP-012: Audit streaming to your SIEM

[ryw]

Status: Draft — open for input · Category: Enhancement

Summary

Stream audit events to your security tooling (Datadog, Splunk, …) in real time, not just exported snapshots, so you can correlate TAS activity with the rest of your compliance infrastructure and alert on it.

Why

Compliance teams live in their SIEM. A point-in-time JSON export doesn't support alerting or correlation; real-time streaming makes TAS a first-class source in the security stack.

Sketch

• Configurable outbound stream of audit events to a SIEM endpoint.
• Standard event schema, at-least-once delivery.
• Scoped per workspace or org.
  (Provisional — the shape changes based on the discussion.)

Open questions

• Which destinations/protocols first (HTTP, syslog, vendor SDKs)?
• Delivery guarantees and backpressure?
• What's the event schema contract we commit to?

How to help

React 👍 if you want this, and comment with your use case, constraints, or pushback. This is a draft Tembo Agent Studio Improvement Proposal (TASIP); your input shapes it before it becomes scheduled work.

[kevine824-alt]

@ryw
This would be very powerful, and it closes the biggest gap we have in the security story: today problems get found after the fact, by someone looking. The Oct 1 credit outage at Carefeed is the example. Streaming events into a customer's own tools means their alerting covers TAS without us building it.

Events that came up in the policy template discussion that I'd want in the stream:

• Runs: started, finished, failed, stopped, with agent, version, run-as, who started it, and cost.
• Run-as: someone being set as the run-as for an automation, and manual runs as another member.
• Changes: definition changes (who, which agent, and whether it expanded reach: new connections, tools, send/write, schedule), automations enabled, disabled or rescheduled.
• Access: connections added, removed or expired, role changes, policy template overrides with the justification, approvals given in paused runs and by whom.
• Viewing: if run visibility gets scoped, someone opening runs outside their own.

One important line: stream metadata, not content. Runs hold what agents read (email, records, financial data). That shouldn't be copied into another system. Reference runs by ID and let people open them in TAS under its permissions.

On the open questions:

• Destinations - start with a generic HTTP endpoint, since Datadog and Splunk can both take it, then syslog for self-hosted customers. Vendor SDKs later. It would also help to point the same stream at simple alerts (Slack or email on failed runs or outages) for customers who don't have a SIEM yet, which is most of the smaller ones.
• Delivery - at-least-once with an event ID so duplicates can be dropped, buffering when the destination is down, and an event when the stream itself falls behind or drops. A silent gap in an audit stream is the worst outcome.
• Schema - versioned, with a small stable core (event ID, type, timestamp, org/workspace, actor, run-as, agent, version, outcome) and only additive changes within a version. Mapping to a standard format customers already use would make it easier to adopt.