eve 0.44.0 Made Agent Traces Public-Only by Default

eve 0.44.0, published on August 21, 2026 at 16:07 UTC, changed the default for agent trace visibility: a content-bearing trace is now created only for conversations the framework classifies as public, while private and unknown conversations fail closed. The release note phrase, “public-only by default,” reads two ways in English, and one of those readings is a leak. It is not a leak. This is a narrowing, and the merged pull request says so in its own words.

The stakes are concrete for anyone running an agent on a messaging surface. A trace can carry system prompts, prompt messages, model responses, and tool arguments and results. Before this release, whether that content was captured was a single static switch with no idea who the conversation was with. After it, the framework refuses by default to create a content-bearing trace for anything it cannot positively classify as public. The same release removed the EVE_TRACES_CONTENT environment variable outright, which means an upgrade silently changes local behaviour for anyone who still has it set.

This post is the delta on top of our eve launch coverage, not a re-introduction. It resolves the direction of the change with verbatim evidence from PR #2335 and the documentation diff in PR #2343, walks through the before-and-after by surface, gives you an upgrade checklist, and reads the five sibling releases from the same week for behaviour changes rather than as a feature tour.

The eve 0.44.0 release was created on GitHub at 16:05 UTC on August 21, 2026 and published at 16:07 the same afternoon. Its changeset is a single sentence: “Make traces public-only by default while retaining unclassified HTTP/TUI sessions in zero-config local tracing, and add composable input/output redaction, span filtering, and attribute filtering to the export pipeline.” The commit behind it, 47e8b64, is titled “feat(eve): configure audience-aware tracing (#2335)” and its body describes “ordered managed export policies for the narrowed audience contract.” The word the author chose is “narrowed.”

Read together, the changeset and the commit describe three distinct pieces of behaviour. The first is a gate on whether a trace is created at all. The second is a carve-out so that zero-config local tracing keeps working for ordinary local testing. The third is a composable export pipeline that redacts or drops content from traces that did get created. Each has its own rule, and the upgrade checklist later in this post treats them separately.

The phrase is genuinely ambiguous English, and it is worth saying so before resolving it. “Traces are public-only by default” can mean that traces are only created for public conversations, or it can mean that traces are, by default, public. The first reading is a privacy narrowing. The second would be a serious visibility widening in a framework that ships iMessage and SMS channels. Secondary coverage that summarises the release-note surface text alone is likely to leave the question open or pick the wrong side.

Three primary layers inside the vercel/eve repository settle it, all dated August 21, 2026 or created earlier that day. The release note uses “retaining” for unclassified local sessions, which only makes sense if everything else is being dropped. The commit message says “narrowed.” And the body of PR #2335, written by the same author, states the mechanism in one sentence.

“Fail-closed” is the operative term. For a private or unknown conversation, no content-bearing trace is created at all unless a developer writes a custom policy that admits it. The same PR adds that the gate applies to adopted sampled contexts, so an incoming traceparent header from an upstream service cannot be used to bypass the local audience policy. Audience is exported only on the agent.session span and is carried to child spans through durable state and internal OpenTelemetry context.

The originating issue confirms the intent from the other side. Issue #2331 describes the problem being solved as trace destinations choosing input and output capture statically, while messaging agents need to retain content for positively public conversations and redact the rest. The motive stated there is a design gap, not an incident. No CVE, breach, or customer complaint appears in the release notes, the PR, or the issue, and this post does not invent one.

The cleanest evidence for the direction of the change is the documentation diff itself. PR #2343 is docs-only and rewrites docs/guides/instrumentation.md and the CLI reference. The lines it removes describe the old default; the lines it adds describe the new one. Placing them side by side shows that “previously everything was traced and now it is locked down” is the wrong mental model. The old default was blanket opt-in silence. The new default is conditional, audience-gated visibility that is open for public traffic and closed for everything else.

One row deserves honesty: the local dev row is the one place this release is arguably a widening. For a local eve dev session classified public or unknown, which covers ordinary local HTTP and TUI testing, full content is now captured by default where it previously required a manual opt-in. That content stays in the local trace store on the developer’s machine, and the store’s budget is unchanged, but a team that treated local traces as metadata-only should know the default moved. Private local sessions still fail closed.

The shipped vocabulary is public, private, and unknown. Every sentence in PR #2335 and every example in the PR #2343 documentation diff uses those three values and no others. eve’s own documented default, expressed as code, is a one-line policy:

import { otel } from "eve/instrumentation/otel";

export default otel({
  tracePolicy: ({ audience }) => audience === "public",
});

There is a terminology discrepancy worth naming so that nobody writes a policy against values that do not exist. Issue #2331, which motivated the work, proposed a four-value vocabulary: public, restricted, direct, and unknown. Its problem statement talks about “redacting direct, restricted, and unclassified conversations.” The merged code and documentation collapse that into three values. Treat restricted and direct as design-history terms, not as live API values, until the repository’s own docs say otherwise.

The reason the vocabulary matters is that a policy is just a predicate over the audience. A messaging agent that wants to trace its public support channel but nothing else already has what it needs with the default. A team that wants traces for private channels must say so in code, and the framework makes that a visible, reviewable decision rather than an environment flag somebody set months ago. That is the right shape for a default in a framework that added a first-class iMessage and SMS channel the day before.

The second half of the changeset is the export pipeline. Once a trace is accepted, it captures complete spans and then runs through an ordered set of export policies. The PR #2343 diff documents four named helpers, agentRuns, composeSpanExportPolicies, redactSpanInputs, and redactSpanOutputs, plus inline span and attribute policy objects that drop a span by name or keep or replace an attribute by key. The documented example composes all of them:

import {
  agentRuns,
  composeSpanExportPolicies,
  redactSpanInputs,
  redactSpanOutputs,
} from "eve/instrumentation/otel";

export default agentRuns({
  exportPolicy: composeSpanExportPolicies(
    redactSpanInputs(({ audience }) => audience !== "public"),
    redactSpanOutputs(({ audience }) => audience !== "public"),
    {
      span: ({ name }) => name !== "internal.cache.refresh",
      attribute: ({ key }) =>
        key === "user.email" ? { action: "replace", value: "[redacted]" } : { action: "keep" },
    },
  ),
});

Two properties of this design are worth more than the API names. First, composition is ordered: the documentation states that composed policies run in declaration order, so the span and attribute policy in the example receives the facade already produced by the input and output redactors. Second, the two gates are independent. The docs say it directly.

For teams that already maintain a redaction layer in front of their observability backend, the natural move is to express it here rather than downstream, because the export pipeline sees the span before any exporter does. The patterns in our AI output PII redaction guide map directly onto redactSpanInputs and redactSpanOutputs, and the attribute-level replace action is the right home for identifiers like an email address that you want present as a marker but never as a value. The anti-patterns we catalogued in our trace-quality post mostly come from capturing everything and filtering later; this pipeline inverts that order.

None of this is a large migration. It is a short list of defaults that moved, and one variable that stopped doing anything. Work through it in order.

1. Delete EVE_TRACES_CONTENT from .env.local and from any shared env template. The CLI reference drops the row outright in PR #2343. If it is still set, it silently does nothing, and the comment next to it will mislead the next engineer. This is the one item the release notes do not call out and the one most likely to be missed.
2. Decide, in code, which audiences you trace. The default is public only. If your agent serves a private channel and you need traces for it, write a tracePolicy that admits it and put it through review. That requires the policy-authoring API, which sits behind experimental.instrumentationProviders.
3. Pair any widened tracePolicy with an exportPolicy. The docs instruct exactly this for private local sessions. The export gate is independent, so the redaction you write there holds even if somebody later widens the creation gate again.
4. Check whether local eve dev traces now hold content you did not expect. Public and unknown local sessions capture system prompts, prompt messages, model responses, and tool arguments and results, each value capped at 32 KB. If developers test against real customer data locally, that content now lands in the local trace store by default.
5. Confirm your upstream services are not relying on traceparent to force tracing. Adopted sampled contexts now pass through the same audience gate, so a sampled upstream request to a private conversation no longer produces a content-bearing child trace.
6. Re-read your exporter’s retention path. The old docs told you to enable content categories only after reviewing it. That advice did not go away; it moved from a blanket switch to a per-audience policy, and the review is now per audience.

If you want a broader pass than this release-specific list, our 60-point agent observability audit covers the retention, access, and redaction questions that sit around any tracing default, and the build-log secret redaction Vercel shipped in July is the same redact-by-default instinct applied one layer up the stack.

0.44.0 was the sixth minor eve release tagged between Monday, August 17 and Friday, August 21, and the second that Friday; 0.43.0 had published at 12:03 UTC, about four hours earlier. Three of the six landed on August 20 alone. The table reads each release for what changed in behaviour, one line each, with the GitHub release as the only source. These are framework-internal API changes that only the vendor can authoritatively state, so treat every row as vendor-stated release-note content rather than independently audited fact.

Two of those rows are behaviour changes in the strict sense. A parent agent written against 0.41.0 that called task_sleep to wait on a delegated task no longer has that tool after 0.42.0 and must rely on lifecycle notifications instead. Likewise task_peek is gone after 0.40.0, with results and failures delivered in the notification itself. The 0.43.0 task.send addition is the constructive half of the same redesign: a background tool reports its terminal result in-process rather than by minting a callback URL. Read in order, 0.40.0, 0.42.0, and 0.43.0 are one story about task lifecycle, and 0.44.0 is a separate story about what a trace is allowed to contain.

Nothing in the week changed eve’s licence or status. The repository remains Apache-2.0 and the framework remains in beta, as it was at launch in June. The separate Agent Runs dashboard, with its Developer and Business modes and retention tiers, was announced on June 26, 2026 and is background context here, not part of this week’s releases.

The interesting trend is not the release itself but what it says about where agent-framework defaults are heading. Most of the observability tooling we work with trains teams to capture everything and filter at the backend. This release moves the decision to the framework boundary and makes the conservative choice the one that requires no code. Combined with the export pipeline’s ordered, reviewable policies, the effect is that an agent’s privacy posture becomes something you can read in a single file rather than infer from an environment and a dashboard setting.

Looking forward, the shape of this change suggests the audience concept will spread beyond tracing. Once the framework knows whether a conversation is public, private, or unknown, that signal can gate more than spans. It is the same signal a memory layer, a logging sink, or an evaluation dataset would want, and it is already carried through durable state to child spans. Whether Vercel takes it there is not something the release notes say, so treat that as our projection rather than a roadmap. What the notes do establish is that private and unknown audiences are now rejected by default at the trace boundary, and that any wider policy is a deliberate, reviewable choice.

If you are building a customer-facing agent on eve or deciding between frameworks for one, this is the kind of default we check first in our AI transformation engagements, and the instrumentation and redaction policies are the sort of code our web development team writes alongside the agent itself rather than after the first incident.