Reviews use staging, sandbox, exported logs, or redacted traces. Production systems are out of scope by default.
Short version for security review.
The engagement is intentionally narrow: one staging workflow, trace-backed authorization evidence, and a report that separates public model-behavior research from customer-specific runtime evidence.
Do not send passwords, API keys, session tokens, private keys, or unrestricted admin accounts.
Use synthetic, de-identified, or redacted data. Harmless canaries replace real secrets.
Client traces are deleted within 30 days after final report delivery, or sooner on written request.
Client traces are not sent to model providers or shared analysis tools unless approved in writing.
Customer trace analysis is local by default. Website hosting and ordinary business email are covered separately in the Privacy notice.
Data handling ledger.
These are the default controls. Contract terms can replace or tighten them for a specific engagement.
One redacted trace or exported log for the first scoreability diagnostic; later, staging traces for selected scenarios if the workflow is ready.
Use a customer-approved secure channel, such as a client portal, encrypted file share, private repository, or agreed secure link.
Traces are kept on encrypted, access-controlled local storage after receipt. Access is limited to the named reviewer, Jiahao Zhang, unless otherwise agreed in writing.
Client traces are not used for model training, public examples, benchmark data, marketing claims, or third-party disclosure without explicit written permission.
Default retention is deletion within 30 days after final report delivery, or sooner on written request. Deletion confirmation is available on request.
Client traces are not sent to third-party LLMs or model providers by default. If your team requests or approves LLM-assisted analysis or another third-party processing path, it requires written approval and minimized, redacted inputs.
Reasonable NDA, MSA, DPA, or BAA terms can be reviewed when the engagement requires them.
What not to send.
Private trace review works best when sensitive data never enters the package in the first place.
- Production credentials, API keys, tokens, private keys, or session cookies.
- Real customer data, PHI, PII, payment card data, or regulated financial account data.
- Raw database dumps, production ledger IDs, production bank details, or unrestricted admin accounts.
- Private traces through public GitHub issues, public pull requests, or public discussions.
Clear scope, clear limits.
This is a focused authorization-boundary review, not a broad certification claim.
What the review covers
Whether a tool-using agent can take a high-impact action without trusted, current, scope-matching authorization evidence.
What the review does not claim
It is not a SOC 2 audit, HIPAA assessment, PCI assessment, full penetration test, SAST, secret scan, or full IAM/MCP configuration audit.
When sensitive traces may be possible
If sensitive data could appear, we pause first and handle redaction, de-identification, NDA, DPA, or BAA requirements before transfer.
Questions before sharing a trace?
Send the data-handling question first. The safest pilot is the one where the transfer path, redaction boundary, and retention rule are clear before the first file moves.
Email jiahao@actionboundary.dev directly, or use the prefilled email link on the intake section. No website inquiry form or third-party form processor is used. Reply within 1 business day.