Skip to main content

Audit before effect

The reason teams give Yekar.AI agents real credentials is simple: nothing happens outside Yekar.AI without a record of it being written first.

Before an agent or flow calls an integration or a model, Yekar.AI opens the audit record - the request, whose account it acts as, whether the call reads or writes, and the fact that it started. Only then does the call go out. When it returns, the same record is completed with the outcome and how long it took.

That ordering is what makes a session a trustworthy account of the work rather than a summary of it. You can hand any session to a colleague, an auditor, or a customer and it will show what was actually attempted, with the exact arguments.

What you see, and where​

Open any session and select the actions line under a reply. Every tool call is there with its input, output, duration, and read/write nature. Flow runs record the same way, anchored to the step that made the call. Nothing is written after the fact and nothing is reconstructed from logs.

Work that pauses for a person​

An agent tool you've chosen to gate is recorded before it reaches the approvals inbox, so the pending call is visible in the session with its exact arguments while it waits. Approving it stamps your decision onto that same record and lets the already-recorded call execute. Rejecting it closes the record without the call ever going out.

This is why an approver can make a real decision: they are looking at the actual request, not a description of one.

If a call is interrupted​

If something fails mid-call - a network drop, a provider timeout - the record stays open, marked as started with an outcome that is unknown. That is deliberate. An open record tells you exactly where to look in the external system; a missing record would tell you nothing at all.

Because the far side is someone else's system, Yekar.AI cannot make a remote operation and its own record of it succeed or fail together. What it can guarantee is that you always know a call was attempted, and that is the guarantee that lets you reconcile.

The organization audit log​

Tool calls are recorded on the session they belong to. Everything else your organization needs to account for - who signed in, who was given access, what changed in its configuration, what was approved, and when Yekar.AI support was inside - is recorded in the organization audit log. Organization Owners and Admins read it under Settings → Audit log, and through the API at GET /api/v1/org/audit-events.

It records, among other events:

  • Sign-in: successful sign-ins (with the method: password, Google, SSO, invitation, password reset, or choosing a workspace), failed sign-ins against a member's address, a sign-in held because the organization requires single sign-on or two-factor sign-in, sign-outs (one session, or all devices), password changes, password-reset requests and completions, changes of sign-in address, and two-factor sign-in turned on or off, a recovery code used (with how many remain) or the set replaced.
  • Access: invitations and the organization role granted, members disabled or re-enabled, domain memberships and roles, approver policy, what each domain role may do (Settings → Permissions), personal API keys created, rotated or revoked, and short-lived access tokens issued from a signed-in session.
  • Approvals, agents and configuration: approval requests and decisions - including each approval recorded while a call waits for more approvers, and a pause skipped by an agent's auto-approve rule - tool approval requirements and how many approvers they need, enforced agent safeguards, model switches, SSO settings and the single sign-on requirement, the inactivity sign-out time, the two-factor requirement, connection settings, and a webhook switched to or from unmasked delivery.
  • Configuration: domains created, edited or archived; agents and flows created, archived or deleted, and which integrations they may use and as whom; triggers and event subscriptions created or deleted; webhooks created or deleted; integrations connected or disconnected, and credentials added, rotated, made active or removed; model-provider keys saved or removed and which providers and models are switched on; your organization's own OAuth apps and which app each integration signs in with; a tool's read/write classification; and every change of plan.
  • Support access and Yekar.AI actions on your organization: each support session requested, approved, denied or expired while you require approval, started, ended or refused, and every change made inside one.
  • Data exports: knowledge-snapshot exports and exports of the audit log itself.

What it deliberately leaves out: no row contains a password, a token or an API key (a key appears only as its yk_…abcd hint), and failed sign-ins never record the address that was typed. Sign-in rows record the network a request came from - the first three parts of an IPv4 address (a /24) or the first 48 bits of an IPv6 address - never the full address. A change of sign-in address records that it happened, not the addresses themselves. A webhook row never records its address, which can carry a token.

Some rows describe work inside a domain. The row is always listed, but its details are shown only to people who can access what it describes: domain rows to that domain's members, and agent activity outside a domain to the person who started it. Details of actions taken by Yekar.AI support are not shown in the audit log; the Support sessions page shows who signed in, why, and every change they made.

Export downloads every row matching the current filters as CSV (or JSON Lines through the API with format=jsonl); there is no row limit, so use the date filters to bound it. Each export is itself recorded in the log. Rows can never be edited or deleted.

Where to go next​

  • Credential handling - which account a tool call acts as, and how the secret is protected.
  • Permissions - who inside your organization can build, run, and approve.
  • Sessions - reading the record itself.