What a reviewer asks for

41% of enterprise buyer respondents say they require detailed audit logs before signing off on an integration platform, per Paragon's 2026 State of Agentic Integrations Report (600 B2B SaaS leaders). Auditability and security review is a real blocker in that same report — 46% of respondents cite it — but it ranks third of six; integration reliability leads at 52%.

That lines up with published audit-log practice. NIST's guidance on security log management treats identifying the entity responsible for an action as a baseline requirement, not an advanced one, and the AICPA's SOC 2 Trust Services Criteria build audit-trail completeness into the security criteria most of the platforms above are evaluated against.

A reviewer evaluating AI agent audit logs specifically should ask which SIEM-forwarding mechanism is in play, not just whether a checkbox exists: Workato, Boomi, Tray.ai, MuleSoft, and Zapier all stream natively — Boomi via OpenTelemetry (GA September 2025), also available as a third-party connector pull (Splunk app, Datadog integration) — and Paragon doesn't forward to a SIEM at all. A fuller reviewer checklist beyond audit logs — SSO, RBAC, breach notification, data residency — is in the integration platform security review checklist. And when the review turns from who-did-what to the data itself — what a sync pipeline retains and who can reach it — that half is covered in passing a security review for data ingestion.

Paragon's model, tied to the capability

Paragon logs integration actions with end-user attribution (actor, action, object, outcome, timestamp), searchable in-product. That's the specific capability the rest of this comparison measures against: which end user, which action, which object, what happened, and when.

This comparison carries two real limits on Paragon's side. Paragon does not offer native SIEM forwarding: actions are logged (actor, action, object, outcome, timestamp) and searchable in-product, not streamed to an external pipeline. Against Workato, Boomi, Tray.ai, MuleSoft, and Zapier, all of which stream natively, the answer today is: pull the data, don't expect a push. Paragon also does not support SCIM-based user provisioning — access to Paragon's own admin console is managed through SSO and role-based access control, and adding new team members is a manual step rather than an automated directory sync.

A third limit is retention. Paragon's Event Logs retain 30 days on Enterprise plans and 7 days on Pro and below — shorter than MuleSoft's configurable multi-year window and Celigo's one-year minimum. A security team whose retention requirement runs past 30 days needs to pull the log into its own storage before it ages out, the same as it would against any platform whose native window falls short of that requirement.

Paragon holds SOC 2 Type II; ISO 27001 is in progress. The fuller certification comparison across all seven platforms is in which integration platforms are SOC 2 compliant.

Where Paragon sits in the audit trail

Each downstream connection authenticates as a specific end user — the customer's own end user, not a shared service account — through per-user OAuth or API-key credentials. That identity carries through to every action an agent calls, whether it's called directly or exposed as a tool over MCP. When the action runs, Paragon logs the acting end user, the action, the object it touched, the outcome, and the timestamp.

Here are the fields a reviewer can expect an Event Log entry to carry, per Paragon's Event Logs documentation — field names only, not an example payload:

timestamp                    // date and time the event occurred
type                         // the Paragon feature emitting the event
message                      // the message associated with the event
projectId
personaId
endUserId                    // the customer's own end user the action was performed for
connectCredentialId
connectCredentialConfigId
workflowId
integrationId                // optional
webhookId                    // optional
eventId                      // optional
eventName                    // optional
status                       // optional — e.g. EVENT_STATUS.SUCCEEDED or FAILED
error                        // optional
traceId                      // optional

timestamp                    // date and time the event occurred
type                         // the Paragon feature emitting the event
message                      // the message associated with the event
projectId
personaId
endUserId                    // the customer's own end user the action was performed for
connectCredentialId
connectCredentialConfigId
workflowId
integrationId                // optional
webhookId                    // optional
eventId                      // optional
eventName                    // optional
status                       // optional — e.g. EVENT_STATUS.SUCCEEDED or FAILED
error                        // optional
traceId                      // optional

timestamp                    // date and time the event occurred
type                         // the Paragon feature emitting the event
message                      // the message associated with the event
projectId
personaId
endUserId                    // the customer's own end user the action was performed for
connectCredentialId
connectCredentialConfigId
workflowId
integrationId                // optional
webhookId                    // optional
eventId                      // optional
eventName                    // optional
status                       // optional — e.g. EVENT_STATUS.SUCCEEDED or FAILED
error                        // optional
traceId                      // optional

timestamp                    // date and time the event occurred
type                         // the Paragon feature emitting the event
message                      // the message associated with the event
projectId
personaId
endUserId                    // the customer's own end user the action was performed for
connectCredentialId
connectCredentialConfigId
workflowId
integrationId                // optional
webhookId                    // optional
eventId                      // optional
eventName                    // optional
status                       // optional — e.g. EVENT_STATUS.SUCCEEDED or FAILED
error                        // optional
traceId                      // optional

Failures are handled separately from the audit log. Workflow and credential failures route to Slack, Datadog, Sentry, or New Relic for real-time alerting — that's failure monitoring, kept apart from the per-action log described above, not a general audit feed.

Paragon's underlying security posture — SOC 2 Type II, per-tenant isolation, encryption at rest and in transit — is published at Paragon's trust portal. To see how the log looks against your own tenant and user model, request a demo.

FAQ

What counts as an "audit log" for AI data access, versus a workflow log? A workflow log confirms a job ran — started, finished, or failed. An audit log for AI data access has to answer a narrower question: which end user's record did the agent read or write, with which action, and when. Most platforms compared here produce the first kind by default. Paragon logs integration actions with end-user attribution (actor, action, object, outcome, timestamp), searchable in-product, which is the second kind.

Does an integration platform identify which end user an AI agent acted as? Not by default, for four of the seven platforms compared here — Workato, Boomi, MuleSoft, and Zapier's own docs identify only the platform's own workspace or admin user who configured or triggered an action; none of the four document a customer's downstream end user in that trail (checked Sept 2026). Celigo and Tray.ai narrowed that gap in 2026 for MCP tool calls only: Celigo surfaces the authenticated end user in its MCP request log once a connection is migrated to its end-user model, and Tray.ai's Agent Gateway records the executing end user under Dynamic Authentication — in both cases only for MCP tool calls, not the platform's wider audit trail. Paragon logs an endUserId with end-user attribution, identifying the specific end user an agent acted on behalf of, without a migration or configuration step.

Can audit logs be forwarded to a SIEM? Workato, Boomi, Tray.ai, MuleSoft (tier-gated to Anypoint Integration Advanced or Titanium), and Zapier (Enterprise) offer native streaming — Boomi's is OpenTelemetry-based (GA September 2025), also available via a third-party connector (Splunk app, Datadog integration). Celigo has no SIEM streaming, only CSV/API export. Paragon doesn't forward them at all — actions are logged (actor, action, object, outcome, timestamp) and searchable in-product.

How long are audit logs retained? It varies sharply by vendor and plan, so no single number represents the field. MuleSoft defaults to one year for new organizations, up to six years for legacy accounts; Celigo holds a minimum of one year; Zapier keeps six months (Team) or twelve (Enterprise); Tray.ai's workflow-execution logs run 7 to 30 days by plan; Boomi shows 30 days in-console with an indefinite underlying store; Workato's docs put it at one year (its marketing page still shows an older 90-day figure). Paragon holds Event Logs for 30 days on an Enterprise plan, or 7 days on Pro and below.

What should a security reviewer ask for when evaluating AI agent audit logs? Ask for three specifics: whether the log identifies the end user an agent acted as, not just the platform user who configured the connection; the actual retention window versus any marketing figure; and whether SIEM forwarding is native — as with Workato, Boomi, Tray.ai, MuleSoft, and Zapier — or absent entirely, as with Paragon. Paragon answers the first with per-action, end-user-attributed logs; the second with a published 30-day (Enterprise) or 7-day (Pro and below) window; the third with a plain no on native forwarding — the data is searchable in-product instead.

Related

• Ai Agent Integration Infrastructure

• Integration Platform Security Review Checklist

• Soc 2 Compliant Integration Platforms

• Ai Agent Tool Calling Access Saas Apps