An agent can act only when every access check allows it. Connection alone does not grant access to the whole team.
Four independent checks
For an operation to succeed, the agent must have:
- an active identity;
- access to the target workspace;
- the required capability; and
- live authority through its steward.
A personal agent is accountable to one human steward. A steward is the person or team accountable for an agent. A team agent is accountable to the team and displays a TEAM badge in the roster, which is the list of connected agents. The badge marks team accountability. Authorized managers may assign an agent to another person or to the team. This does not automatically add workspaces or capabilities.
Capabilities
A capability allows one type of action. The available capabilities are:
| Capability | It can |
|---|---|
read |
Open and read artifacts in granted workspaces |
write |
Change artifact content in granted workspaces |
share |
Use supported sharing controls |
publish |
Deploy an artifact to a public URL |
A workspace grant gives the agent access to one workspace. It decides where these capabilities apply. Stewardship identifies who is accountable. Neither is a substitute for the other.
What an agent cannot do
An agent cannot:
- grant itself a workspace or capability;
- exceed its steward's live authority;
- infer access from team membership or an artifact URL;
- use a human's password or browser session;
- hide its writes, which remain attributed in artifact history; or
- consume a team seat.
Capabilities cannot be edited in place. An authorized human must revoke and approve the agent again to use a different capability set.
Workspace-scoped data access
An agent can reach only workspaces explicitly granted to it. People and agents in the same team may have different workspace access. Put sensitive work in a workspace whose access list excludes the agent, and verify grants in Workspace access.
Publishing risk
publish creates a URL anyone on the internet can open. Agents are instructed to publish only when explicitly asked, but instructions are not enforcement. Do not grant publish when public deployment would be unacceptable.
Stop or reduce access
- Revoke the identity from current agent administration to stop it everywhere on the next request.
- Remove a workspace grant to stop access only in that workspace.
- Assign the agent to another person or convert it to a team agent when responsibility must change.
If the original steward leaves, an authorized manager should assign the agent to someone else, convert it to a team agent, or revoke it. Existing artifacts and attribution remain. See Revoke an agent.
Current audit sources
Artifact history shows writes and attribution. The hub owner filter shows artifacts an agent created. Current agent administration and workspace access controls show present authorization state. A dedicated audit-log view including reads is still being built.
A connected agent may continue working while human operators are offline, within its live workspace grants, capabilities, and stewardship authority.
Questions and answers
Does connecting an agent expose the whole team? No. It can reach only explicitly granted workspaces and use only approved capabilities within the steward's live authority.
Can I prevent public deployment by telling the agent not to publish?
Instructions are not an access control. Do not grant publish if a public URL would be unacceptable.
How do I reduce access without revoking the identity? Remove the relevant workspace grant. To change fixed capabilities, revoke and approve the agent again.
Where can I verify what it changed? Use artifact history for writes and attribution, the hub owner filter for created artifacts, and administration controls for current access.