Security boundaries for an AI operating inside your product.
A practical overview of Kami's current access model, action safeguards, data boundaries, and deployment responsibilities.
The signed-in user is the access boundary
The host application authenticates its user and supplies the tenant and user context. In production, verified host identity is authoritative; browser-supplied values must not elevate access.
Kami works through what the signed-in user can already see and do. The host remains responsible for account lifecycle, access decisions, session termination, and the correctness of its identity integration.
Consequential actions stop at a clear boundary
- Ordinary work explicitly requested by the user—such as saving, editing, submitting, sending, publishing, inviting, assigning, and rescheduling—does not require the same approval twice.
- Deletion, removal, refunds, consequential cancellation, actual payments or transfers, and credential or authentication changes require confirmation immediately before commitment.
- Risk is recomputed from the selected live control and action semantics; model output cannot lower a required confirmation boundary.
- Users can stop tasks, and Kami distinguishes observed success, observed failure, and outcomes it could not verify.
Browser and application limits
The embedded SDK observes and operates the application interface where it is installed. Ordinary embed JavaScript does not receive unrestricted browser-chrome, operating-system, cross-origin, or third-party-frame control.
CAPTCHA, multi-factor authentication, native browser pickers, protected browser surfaces, and unsupported third-party frames may require an application integration or human handoff. Kami should report that boundary rather than claim completion.
Data minimization and provider credentials
The planner receives the user request and the page or product context needed for the task. Known sensitive values are minimized or redacted before model use, and application logs are designed to avoid secrets and tokens.
Long-lived model credentials remain server-side and must not be embedded in the public site or SDK. The microphone creates one request-scoped transcription upload, places editable text in the composer, and does not auto-submit a command.
Production responsibilities
- Kami protects server-side secrets, verified tenant and user boundaries, action safeguards, material action records, and deletion controls.
- Customers integrate signed identity, approve origins and environments, grant appropriate host access, protect their sessions, and provide the notices required for their users.
- Production deployments must use HTTPS origins, independent secrets, durable backed-up storage, verified identity, and reviewed provider configuration—not development bypasses or demo data.
Assurance status
Kami does not claim SOC 2, ISO 27001, PCI DSS, HIPAA eligibility, or another certification or regulated-data status unless a current scope and supporting report are expressly published.
Use the contact page to request a private security discussion. Do not place live credentials, API keys, or unnecessary personal data in a booking message.
Discuss your security questions
Use a short call to discuss the integration, data flow, model hosting, or your security review.
Book a conversation