Stripe's Kai separates user access from task context. Your knowledge agent should too.

Stripe calls its internal knowledge AI platform Kai. In Stripe's July 30 engineering post, the company describes a strict requirement: data from unrelated customer contexts must never appear in one analysis, even when the user may access each context separately. This is a task-context isolation problem, and a failure could expose customer or business information inside an otherwise authorized session.

That distinction matters before a team connects more sensitive sources to a knowledge agent. A permission check can approve both sources while leaving the session too broad for its current job. This article explains user authorization, task context, and execution isolation, then gives teams a small negative test for the boundary between two separately allowed contexts.

Authorization can be wider than one session's purpose

Authorization decides whether a person or system may access a resource. An application can use an identity token to check whether an employee may read a document store, query a data source, or call a tool. If the checks succeed for two sources, authorization has done its assigned job: it has confirmed the user's permitted access.

A task needs a narrower decision. Task context is the set of data, tools, files, and session state that an agent may use for one defined job. An employee's role can require access to several unrelated business contexts. That broad job access does not give every session a valid reason to use all of them at once.

This concern differs from retrieval that filters results by document permissions. Our Bedrock Managed Knowledge Base analysis covers authentication, identity propagation, document permissions, connector freshness, and allowed or denied retrieval. Stripe's example starts after authentication and authorization have succeeded. The remaining decision is whether the current task may use a source that the current user is already allowed to open.

Three boundaries control different parts of the session

User authorization controls the person's access. It decides whether the employee may access the source. Stripe contrasts this authorization-token scope with task scope, but its post does not disclose the identity architecture or policy service behind Kai. The distinction is a design principle from Stripe, not a public specification of Kai's internals.

Task-context isolation controls what one session may use. It decides whether the task should view an authorized source in its current context. Stripe's invariant gives the required result for unrelated customer contexts: both can be valid for the user, while only one is valid for the session. Stripe does not publish its exact rule language, block behavior, context propagation, or state-restoration process.

Execution isolation controls where tools, code, files, and session state run. Stripe says Kai's shared execution environment includes an agent harness, workflow orchestration, access controls, a secure per-session sandbox, secure code execution, and a multi-tenant virtual filesystem. Those controls matter because an agent can place sensitive data in files or processing state as well as in its final answer. The post does not disclose the sandbox internals, so readers cannot infer guarantees beyond Stripe's published description or treat Kai as a product they can deploy.

Shared infrastructure still leaves domain owners in charge

Stripe describes Kai as three connected layers. Surface-independent APIs support the same service across its web application, Slack, browser-embedded use, and internal applications. AgentStudio lets domain owners build, test, and monitor skills, agents, and tool selections, while a shared execution environment supplies common session, tool, code, and file services.

This design responds to a problem Stripe says it had before Kai. Teams had built more than 4,000 workflow-specific micro-agents, while their instructions varied in quality and the maintenance burden grew. Shared infrastructure can reduce duplication. Domain judgment remains distributed, so Stripe says AgentStudio gives owners usage and quality signals for their skills and agents.

For another organization, the practical lesson is an ownership split. The platform team can own common identity, session, tool, and execution services. Domain owners still need to define which contexts may be combined, who approves exceptions, how changes are reviewed, and what a failed isolation check does to active work. A broader set of AI workflow controls can connect those decisions to approvals, monitoring, and recovery.

Long sessions make early context mistakes persistent

Stripe says one Kai session reached 932 turns and that Kai connects to more than 1,000 skills and tools. These figures describe scale and technical reach inside Stripe. Later work can depend on data, tool results, and files produced earlier in the same session, so task context must remain valid across turns.

If an unrelated source enters the session early, a later answer can reuse that information without retrieving the source again. Code execution can process it, and the virtual file system can retain an intermediate result for later turns. A boundary that checks only the final request would miss state already present in the session. This is a general consequence of stateful agents; Stripe does not disclose how Kai propagates or removes task context internally.

The current collaboration limit matters too. Stripe says user context is currently locked inside sessions and describes sharing across sessions and users as future work. Any team that later adds session sharing must repeat the isolation analysis for copied files, shared outputs, and inherited state instead of assuming that a per-session control covers those paths.

A two-context negative test checks the missing boundary

A negative test checks that a prohibited action fails. Set up two nonproduction contexts, A and B, with one small synthetic record in each. Give each record a unique text value, and authorize the same test identity to access both sources. The permission checks should pass for A and B separately, so the test reaches the task-context boundary instead of retesting authentication.

Start a fresh session whose allowed task context is A. Ask for the value in A, then ask the agent to retrieve or compare the value from B without changing the session context. The first request should succeed, and the second should withhold B even though the identity may access it. Inspect retrieved source material, tool requests, generated files, execution state, and retained logs; a safe final response does not prove isolation if B entered an earlier stage.

Repeat the sequence in a fresh session limited to B, with A as the prohibited source. Then start another fresh session and explicitly request a combined analysis of A and B. The system should block the mixed use before either context crosses into the other's session state. Your team must define the expected response because Stripe does not publish Kai's block or error behavior.

Continue each allowed session after the denied request. Confirm that the agent can still use the allowed context and that the denied context did not remain in files, tool output, or retained state. Run the same test after changes to context selection, source connectors, tool permissions, session reuse, and sharing behavior. The domain owner should review failures with the platform team before either source is connected to production data.

Add more data only after the task boundary holds

The next connection decision should depend on evidence from the two-context test. A passing system lets the same identity use A and B in separate sessions, blocks mixed use, keeps denied data out of intermediate processing, and assigns exceptions and recovery to a named owner. The managed agent, model, or sandbox supplies only part of that result; local rules, integrations, reviews, and operating habits supply the rest.

BaristaLabs can conduct a scoped task-context review for teams that need to trace this boundary through their sources, tools, session state, and review process. If the current design can only answer what a person may access, the team is not ready to combine unrelated business contexts in one knowledge-agent session.