Insights
Security by Design: How Enjamb Keeps Agents Under Control
The control architecture behind delegated identity, per-action permissions, approval gates, revocation, and a reviewable record of every run.
by Enjamb Team
An agent can search, analyze, draft, and act across several systems in one run. That reach is useful only when the organization can decide exactly where it ends.
Enjamb treats control as part of the execution architecture. Authority is checked beneath the model, consequential actions pause for a person, and the evidence behind each run remains available after the work is complete.
Controls live below the model
A system instruction can describe what an agent should do. It cannot be the final enforcement boundary for what the agent is allowed to do.
Enjamb evaluates authority at the system and tool layers. Permissions can be set per person, per agent, per connected system, and per individual action without widening any of the other boundaries.
- Always allow routine, low-risk actions
- Require approval for consequential writes or execution
- Make destructive or out-of-scope actions unavailable
Identity travels with delegated work
The agent acts with the authority of the person who made the request, not a shared credential with broader access. Source-system permissions therefore remain the first boundary around every query and action.
This also makes revocation immediate. Deactivating a person's account removes the authority of every session, connector, and active agent run acting as that person.
Delegation should increase capacity without creating a second, invisible permission model.
Approval is part of the run
When an agent prepares a deviation closure, submission update, or another governed change, the write can stop before it reaches the system of record. A named reviewer receives the proposed action with the request and supporting context needed to decide.
Approval is recorded in the same run as the action it released. A reviewer does not have to reconcile an email decision with a separate automation log after the fact.
The audit record is produced as the work happens
A complete run history retains the requester, instruction, tool calls, systems touched, results returned, refusals, and approvals. Source documents and records remain attached to the claims they support.
That record helps a team answer the operational question behind every audit: who asked, what ran, what changed, what evidence supported it, and who approved the consequential step.
