Repository navigation
feat(logging): Audit credentialed egress writes with one identity model - #2214
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Add logAudit, an info event that Sentry keeps in production, and use it for credentialed egress requests that use a write grant. The event names the credential actor, the delegated subject, and the Automation it is bound to. Refs #2211 Co-Authored-By: David Cramer <david@sentry.io>
…ents Carry the run's conversationId in the signed sandbox egress credential token and in plugin egress, and log it as gen_ai.conversation.id. It is telemetry only and does not grant access. Refs #2211 Co-Authored-By: David Cramer <david@sentry.io>
…ox egress Use OTel user.* for the accountable person instead of enduser.*. For a system run with delegated credentials, user.id is the credential owner. app.actor.* says who acted. app.credential.allowed_when and app.task.id say why delegated credentials were allowed. The sandbox egress proxy now binds the same fields from the signed token, so its spans, logs, and errors carry the person. This replaces the app.credential.actor.* and app.credential.subject.* audit fields. Co-Authored-By: David Cramer <david@sentry.io>
sentry-junior
Bot
force-pushed
the
feat/audit-log-egress-writes
branch
from
October 23, 2026 09:35
3c9b88d to
58eab83
Compare
sentry-junior
Bot
changed the title
dcramer
approved these changes
Oct 23, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In production,
logging.tsdrops all info logs before they reach Sentry. Because of this, we had no searchable record of the provider writes that Junior makes through credentialed egress. That includesghandcurlwrites and workflow dispatches.This PR adds
logAudit. It emits an info event markedapp.log.audit: true, and Sentry keeps that event in production. Other info events stay suppressed as before.sandbox.egress.upstream.requestednow useslogAuditfor requests that use a write grant. Read-grant requests still log only outside production.One identity model. Before this PR, Junior bound the person in different ways on different paths. Slack turns got both
enduser.idand Sentry'suser.id. Automation runs got no person. Sandbox egress got nothing. Now runs, resumes, and the sandbox egress proxy bind the same fields:user.id,user.name,user.email,user.full_name: the accountable person. For a user Actor, this is that user. For a system Actor with delegated credentials, this is the credential owner, such as the Automation creator. These are OTeluser.*fields. Sentry already writes them from the scope user and uses them for its user features.enduser.*is removed.app.actor.type/app.actor.id: who acted,userorsystem.app.credential.allowed_when/app.task.id: why delegated credentials were allowed, and for which Automation.gen_ai.conversation.id: the Conversation. The sandbox proxy handles each request separately with no log context, so the run'sconversationIdnow travels in the signed sandbox egress credential token. It is telemetry only and grants nothing.credentialLogContextandactorLogContextincredentials/context.tsown this mapping. The proxy binds it from the verified token and sets the Sentry user. One run never has two different people: a delegated subject exists only with a system actor (credentialContextForActor).TELEMETRY.mdhas a new Identity section and an updated query recipe.The record has metadata only: provider, grant, method, host, path and status. It has no request or response bodies.
Known gap: an Automation in system credential mode has no delegated subject, so its writes have no
user.id. Naming its owner needs the dispatch to carry the owner. That is a follow-up.Rollback note: the token schema is strict. If we roll back after this ships, the older code rejects tokens that already carry
conversationIduntil they expire (30 minutes at most), so sandbox egress for active sandboxes fails during that time.This is a stopgap. Sentry log retention is not audit retention.
Part of #2211.
via David Cramer.
--
View Junior Session [Sentry]