← Agent Engine

Identity and permissions

agent-engine · workzone

An agent reads company knowledge — so something has to decide which identity it sees that knowledge under. This is not a user setting or a line in the prompt, but a frame the engine binds to the run. The frame is simple: the agent acts under its owner's permissions — it sees exactly what the employee sees, and read-only.

The agent frame — an engineering layer

“Which identity the agent reads the knowledge base under” is decided neither by the admin nor by the prompt itself, but by the agent frame — an engineering layer the engine blends into prompt composition and uses to filter every request to knowledge. The prompt can be spoofed with words — the frame cannot: it is imposed from outside the loop. The engine sets the owner's identity in the frame, and all reading runs under their ACL.

Owner
employee who created the agent
▸ grants
identity
agent frame · engine
run identity
imposed from outside, unbeatable by the prompt
identity = owner
▸ reads
under ACL
Knowledge Store
permission-scoped · read-only

Under the owner's permissions

The agent inherits the creator's ACL in full: their projects, spaces, channels. What is closed to the employee is closed to their agent too; permissions are applied on the Knowledge Store side by a pre-filter — the same mechanism as in live search. The agent has no identity model of its own — it is its owner before the knowledge base.

Owner's identity
  • frame = creator's ACL, one scope per agent
  • permissions change together with the owner's permissions
  • revoke access → the agent narrows in step, the ACL is live
  • no need to choose “whose ACL” — there is only one
v2 full identity model
  • service accounts with their own access
  • choice of “under whose identity” at creation time
  • scope facets: personal · team · company
  • a team agent under the team's permissions, not the author's

Linking an agent to its owner is cheap: the employee's identity is already reconciled with their account (the identity.user_id bridge in the identity model), and the run's FK to the owner leads straight to that ACL — see agents.

This concerns the live ACL of an active employee. An owner leaving is a separate mechanism: deactivation flips the agent's switch off (enabled=false), deleting the account removes it by cascade — see owner lifecycle.

The boundary: read-only

Whatever an agent may “decide,” it writes nothing to the Knowledge Store. All three tools — search, graph, sql — are read-only; writing to the graph (entities, edges, vectors) belongs to knowledge curation and ingestion, not the agent. Two consequences follow: a run cannot corrupt the base, and its reads run comfortably in parallel with graph writes — there is nothing to contend over.

Before the KS, the agent is indistinguishable from the owner: the request runs under their identity, and there is no separate access log on the KS side. The trace of an automated run lives in the run journal; telling “agent or human” apart inside the KS audit itself is v2, along with a KS access log.

Writing an agent's results back into the graph as new insights is a meaningful but separate branch: v2, with its own write-permission perimeter. The agent's output stays in the run journal, outside knowledge.