Agents as first-class principals

The same small set of primitives governs users and agents alike. Principals, which are users, agents, and groups of them, receive access. Resources, which are files, skills, workflows, connector tools, and even other agents and their settings, are the things access is to. Roles bundle permission grants, and a grant is a scoped capability on a resource.

That is the whole vocabulary, and it does not gain a new word for agents. An agent is granted access the same way a person is, with the same primitives, which means a security team reasons about agents in exactly the language it already uses for everyone else. Nothing new to learn, and nothing about agents that the existing model cannot express.

Access is explicitly opt-in. Without a matching grant, a policy that allows it, and any approval the action requires, a request fails closed. This is the familiar fail-safe posture, and it applies to agents with no asterisk.

An agent starts with nothing and receives exactly what it is granted. Silence is denial. The agent that was never given a delete grant cannot delete, no matter how it is prompted, which is the same sentence you would write about a new employee's account on its first day. The default is not a special weak mode for AI. It is the same default everyone else starts from.

Real access is rarely a single role. A principal, person or agent, can hold a direct grant on one resource, inherit grants through a group, and hold several roles at once. The system does not collapse this into one effective role and call it a day.

It evaluates every active path and takes the union of permitted capabilities, then applies any matching denial overrides, which take precedence over the union. After that, workspace boundaries, policies, revocation, and validity windows are checked before anything executes. A denial always wins, and the checks always run at the moment of the action, not once at the start of a session.

Concretely, one agent might be a workspace viewer through a group it belongs to, hold connector-tool access through a second group, and have a direct grant on a single skill. Three independent paths, three different scopes, all live at once. The effective access is their union, minus anything a denial override removes. Flatten that to one role and you have lost the ability to say where each piece of access came from.

Keeping every path visible, instead of flattening to one role, is what makes access reviewable. When a reviewer asks why an agent can read a folder, the answer is a specific path: this grant, or this group membership, or this role, with this scope and this status. Nothing is hidden behind a summarized label.

You can answer what can this agent access and why with the actual grants, not an inference from how it has behaved. For agents, where you cannot interview the principal about its intentions, that auditability is the whole game. The permission graph is the explanation, and it is the same graph you would read for a person.

Access can also be time-bounded. A grant can carry a validity window, so an agent provisioned for a one-off project loses its access when the window closes, with no one having to remember to revoke it. Revocation and expiry are part of the same graph, and the audit log records when a grant was added, when it lapsed, and who changed it.

Because a grant carries a scope, agent access can be cut very fine. A diligence agent can be given read on one folder and the search tool on one connector instance, and nothing else: not the connector's create or delete tools, not the rest of the workspace. A workspace-automation agent can be allowed to create connector instances without receiving any file access. A support assistant can inherit a rep's read access for routine work while still needing approval to send anything externally.

None of these is unique to agents. They are ordinary grants with narrow scopes, and the same scoping is available for people. Agents just tend to need it more, because you grant them deliberately and for one job, and least privilege is easiest to hold when the access was scoped tightly on the way in. A person accumulates broad access over years. An agent should be born with exactly the access its task requires, and no more.

A workspace is the security boundary for the people, agents, data, and tools that belong together. Membership, roles, grants, and connector access are all evaluated inside it. Crossing the boundary is deliberate. Cross-workspace access requires an explicit grant, an admin policy that permits the sharing, and an audit record naming the principal, the resource, and the approving policy.

An agent does not leak access across workspaces because it happens to have a foothold in one. The boundary holds for agents exactly as it holds for people, which is the property you want when an agent is reaching across several sensitive areas of a company at once.

Within this model, agents come in two shapes, and the difference is about whose authority they carry. An assistant is a private extension of one user's authority. It acts on behalf of that person, inherits their relevant permissions, and cannot be opened or used by anyone else. It is personal delegation, and its access moves with the owner's: when the owner loses access to something, so does their assistant.

An independent agent is a shareable service identity with its own grants, its own audit trail, and its own access surface. It is a thing an administrator provisions, and others can be permitted to invoke, configure, or manage it, the way you would handle any shared service account. Both go through the same authorization layer. One borrows a person's authority; the other has its own. Neither gets a path around the checks.

The two shapes map onto real roles. An assistant fits user-directed work: a personal research helper that should see exactly what its owner sees and nothing more. An independent agent fits shared infrastructure: a log-analysis agent with standing read access to selected production logs, a project-management agent that can summarize work and draft updates inside one workspace, a support-triage agent scoped to a single queue. Each is provisioned once, granted narrowly, and audited under its own identity.

One more consequence of treating agents as first-class: an agent is not only a principal, it is also a resource. Access to an agent, the right to invoke it, configure it, or change its grants, is itself granted and audited.

So you can let a business user invoke a diligence agent without letting them change what it can reach, and you can separate using an agent from administering it. The same primitives that govern access to a file govern access to an agent. There is no corner of the system where agents fall outside the model, because the model was built to include them from the start.

The shortcut, a separate little permission system for the AI, saves a week and costs you the ability to answer the questions that matter: what can this agent do, why, and who said it could. Put agents in the same model as everyone else, with the same primitives, the same deny-by-default, the same boundaries, and those questions have real answers. An agent is a principal. Treat it like one, and the security team already knows how to reason about it. It is not a new kind of actor to be governed by a new kind of system. It is a new principal in a model the company already runs.