Coding agents create an awkward security moment. A developer can understand the task they typed and still have no compact answer to a more important question: what is about to leave this machine?
The answer may include more than a prompt. It can involve file contents, paths, repository metadata, environment details, identifiers, or a separate upload flow. Network inspection can reveal those details after enough work, but that is the wrong level of friction for a decision that happens every time someone submits a sensitive task.
A recent Grok Build analysis makes the design problem concrete. In a wire-level test of Grok Build 0.2.93, the author reports that the CLI sent contents from files it had read and used a storage interface to upload the repository and Git history. That is one reproducible report about one observed version, not a claim that every version or coding agent behaves the same way. xAI had announced early access to Grok Build for SuperGrok and X Premium Plus subscribers on May 25, 2026.
The useful product question is not whether developers should trust or distrust a specific vendor. It is whether a coding agent can make the outbound decision inspectable before transmission rather than leaving it to a packet capture afterward.
The receipt should describe this request, not the privacy policy
A generic privacy notice cannot answer which repository, files, paths, and metadata are included in the next request. An outbound receipt can.
Immediately before transmission, the CLI would pause and render a structured inventory:
- prompt and conversation context;
- file fragments and complete files;
- repository or archive uploads;
- file paths and repository metadata;
- environment details and identifiers;
- destination endpoint and client version.
The list should represent what the client has actually assembled. It should not be generated from a static documentation table or a guess about what an agent normally sends.
The first receipt in a repository deserves the most attention. Later receipts can emphasize the delta: a newly included directory, a larger archive, another upload endpoint, or a field that was absent in the previous client version. A developer should be able to understand the change without reading raw JSON.
Approval is not enough; editing is the useful interaction
A modal with only Allow and Cancel turns inspection into ceremony. The receipt becomes more useful when each item can be changed in place.
For example, the developer could:
- remove a file or path from this request;
- replace a secret-looking value with a local placeholder;
- exclude Git history while keeping selected working files;
- approve the remaining payload once;
- save the final receipt locally for review.
This is deliberately narrower than a general data-loss-prevention system. It does not need an organization-wide classification engine to help one developer notice that .env.example, an internal path, or the entire Git history is included in a request.
The tool should also make its limits visible. Redacting a displayed field is meaningless if a second upload path still contains the original value. The receipt therefore has to be generated after the final payloads are assembled and cover every outbound request involved in the submission.
A local record can catch client drift
After approval, the tool can save a small local record containing the receipt, timestamp, destination, and CLI version. The record should avoid duplicating sensitive source material by default; hashes, field names, byte counts, and explicit redaction markers may be enough for comparison.
That creates a practical review surface. A security lead can compare two versions and ask why repository history appeared, why payload size changed sharply, or why a new endpoint was introduced. The artifact does not prove what a remote service retained, and it should never claim to. It records the client-side transmission decision that the user approved.
A team policy can then remain simple and auditable:
- always pause before repository or archive uploads;
- block known secret patterns unless they are redacted;
- require a second approval when new outbound fields appear;
- retain metadata-only receipts for a defined period;
- fail closed when the interceptor cannot parse a changed protocol.
That last rule matters. If a client update changes certificate handling, request structure, or its storage protocol, silently falling back to pass-through would defeat the product. The user needs an explicit message that the receipt is incomplete and that transmission did not proceed.
The smallest credible implementation
A first version only needs to support one tested Grok Build release and two paths: model requests and repository storage uploads. It can run as a local proxy or wrapper, parse those requests into a fixed schema, and present the receipt in the terminal.
The acceptance criteria are concrete:
- nothing leaves before the receipt is rendered and approved;
- prompts, file content, paths, identifiers, and repository uploads appear as separate items;
- removing or replacing an item changes the final outbound payload;
- the saved local record identifies the CLI version and approved fields;
- an unknown request shape stops transmission instead of bypassing inspection.
A reproducible demo should use a disposable repository with fake keys and compare the approved receipt with a captured outbound session. That would test the core promise without asking users to trust another opaque security layer.
The strongest case against it
The protocol may change too quickly. A third-party interception layer could become a permanent compatibility project, and certificate pinning or encrypted upload formats may make reliable parsing impossible. A wrapper can also create a false sense of safety if the agent launches another process or transmits through a path the tool does not observe.
There is a usability cost as well. If every request produces a large checklist, developers will approve it mechanically. Useful defaults must therefore make small, repeated payloads quiet while forcing attention onto meaningful changes. The product has to prove that its inventory is complete and that editing the receipt really edits the bytes being sent.
Those constraints are why this should start as a narrowly tested, version-bound tool rather than a universal promise for every coding agent.
The source list, observed-version boundary, complete product brief, and implementation caveats are on RayTally's Grok outbound receipt page.
What would you need to see before allowing a coding agent to upload a repository: a file list, a payload diff, an endpoint inventory, a local audit record, or something else?
