Technical
How Enjamb Protects Customer Data
How identity-bound access, scoped connections, retention controls, and attributable runs keep customer data under customer control.
by Enjamb Team
Customer data includes the information an organization provides, connects, or generates through Enjamb: prompts, uploaded files, source records, tool results, and the outputs created from that work. It remains the customer's data.
Protecting it requires more than a promise inside a model prompt. Enjamb places identity, permissions, approvals, and the activity record around the model so the same controls continue to apply from the first request to the final action.
Access begins with the person who asked
An Enjamb agent acts as the person who requested the work. It cannot open a study, document, dataset, or system that the requester's own account cannot reach.
That boundary continues across connected systems. Each connector can be limited to the sources and actions required for the workflow, so connecting a system does not turn the agent into a shared superuser.
- User-level access follows the requester's existing permissions
- Read and write capabilities are scoped per connected system
- Individual actions can be allowed, held for approval, or unavailable
Customer data is used to do the requested work
Enjamb does not use customer inputs, outputs, or uploaded files to train its models. The model providers Enjamb runs on are also prohibited from using that data for model training.
The organization decides which sources Enjamb can use and how long information is retained. Retention and deletion controls can be aligned to the workspace and the connected workflow rather than imposed as one policy for every kind of work.
The customer chooses what Enjamb can reach, how the information is retained, and when it is removed.
Sensitive actions stop for review
Reading a source and changing a regulated record should not carry the same authority. Permissions are set at the action level, and a consequential write can wait for a named reviewer before it runs.
The reviewer sees the proposed action in the context of the request that produced it. If access is revoked while a run is active, the agent loses that access with the person it represents.
Every run leaves a reviewable record
Each run connects the named requester, their instruction, the systems involved, the actions attempted, and the approvals that released them. Refused actions remain part of that history too.
The resulting source trail makes it possible to review how an answer or system change was produced without reconstructing the work from separate logs and files.
