Enterprise Tool Access Model

Three independent layers must agree before the agent can act:

1. Network reach (allowlist). Destination is reachable from the workspace boundary.

2. Per-service authentication. The service’s own credentials are valid and scoped.

3. Action class (per blueprint). The agent is permitted to perform this category of action against this service.

Where credentials live. Held by the credential proxy in the runtime layer (in-VM by default). The agent receives capabilities; the proxy executes the call on its behalf; raw secrets never enter the agent process.

How authorization decisions are made. Identity and authorization are separate concerns. Identity is established upstream — the four-identity chain (user/sponsor via SSO, workspace, logical agent, per-call runtime credential), resolved back to the sponsor before any tool access. Authorization is the per-engagement delegation record — a policy-defined subset of the end-user’s permissions — evaluated and enforced centrally at the runtime layer, never a separate authority and never re-implemented by each application.

Downstream systems keep enforcing their own per-service authentication and native permissions; Secure Agent Workspace narrows the agent to the delegated subset on top of that. No application needs to understand agent delegation — it sees a credential acting within the user’s existing permissions.

Delegation is strictly attenuating. A child delegation record can only narrow its parent’s scope, tools, resources, and duration — never widen them. A child holding {A,B} cannot delegate {A,C}: although C is within the root’s {A,B,C}, C is not in the child’s authority, and a child cannot grant what it does not hold. Re-acquiring a dropped authority is not a lateral grant — it requires a fresh delegation from a principal that still holds C (the sponsor or root task), under the same review and audit. Every chain stays a monotonic subset of the root, so subagents cannot re-escalate privilege.

Concurrency across agents. The access model and the realization pattern are per-agent: each agent writes to its own branch, scratch, or draft and reaches a shared source of truth only through a reviewed MR/PR — so two agents should not hold write access to the same mutable target in the first place. Where a shared target is unavoidable, Secure Agent Workspace does not add a cross-agent coordination layer; concurrency is delegated to the system of record’s own controls (locks, optimistic concurrency, review queues). Detection relies on per-action attribution: every write is stamped with the user, agent, and delegation record and emitted to the audit log, so a collision — agents A and B writing the same branch — is visible after the fact even when it is not prevented.

Table 5: Service Category Access Model

Service Category	Autorun (no review)	Human-in-the-loop review
Source control	Search, read, clone, branch, draft patch, run tests in workspace	Merge, push to protected branch, tag/release, repo-settings change
Work tracking / ticketing	Search, read, draft update or comment	State change, assignment, closure, field/priority change
Documentation / wiki	Search, read, draft page or edit	Publish, move, delete
Chat	Search, read, summarize, draft message	Send, broadcast, channel post
Mailbox	Search, read, summarize, draft response	Send, forward, reply-all, delete, archive
Package repositories	Resolve/install from approved mirrors; read package metadata	Add a source/mirror, publish a package, version pin/override outside policy
Data stores	Read and query within explicit dataset scope	Write/update/delete, widen dataset scope, export outside scope
Model endpoints	Inference on approved endpoints via routed access, within blueprint policy	Non-default/unapproved endpoint; sending a restricted data class to a model
External internet	Read-only fetch from explicit allowlist	Any non-allowlisted destination, outbound write/POST, allowlist change

What’s autorun vs. reviewed. Read, search, summarize, and draft are typically allowed without review when inputs are trusted and outputs are consumed by a human. Untrusted data, write actions, or output consumed by another agent without HITL must always trigger human review.

Draft means producing the content, not committing the consequential action — whether held in the agent’s context (copy/paste-ready) or written as a draft object on the service (draft email, branch, unpublished revision, proposed ticket state). A server-side draft is a write, but to a private, reversible staging surface — the human-review gate of §6, not a consequential write — so it remains autorun. The gated action is send / publish / merge / assign / delete, never the draft itself. A draft that is not private and reversible (visible to others, or triggering notifications) is treated as the consequential write and requires review.

Prefer structured integrations. Where a capability can be delivered through more than one integration shape, choose the most structured one: a scoped MCP server (privileges, scopes, and secrets held outside the agent’s view) over a CLI client (which can surface secrets into the agent context) over an ad-hoc network script (unstructured, secret-exposing by necessity).