Git Workspaces: AI Agents Get a Branch, Not Credentials

AI coding agents can now write, run, and push code into production repositories—but the real security question is not what they can do, it is what your credentials allow them to do. Pragor's answer, announced on 6 October 2026, is a deliberately narrow boundary: Git workspaces give an agent a writable checkout and a branch, and withhold your credentials, network, database, and any path to self-granting extra authority.

What a Git workspace actually grants

A Git workspace is a writable checkout bound to one repository, one task, and one assignee, created from an immutable base commit. The agent reads it, changes it, runs commands in it, and submits; delivery is forward-only to a derived branch. Pragor does not force-push and does not alter the configured remote once a repository mutation has started.

What the agent does not receive is where the model becomes concrete:

• Not the credentials. Upstream write credentials are installed by a human board operator against a provider-pinned HTTPS origin, referenced by an opaque slug, decrypted only for the single outbound request that needs them, and never returned to the controller or runtime.
• Not the network. Repository commands run with no network access, as a non-root user, with bounded CPU, memory, process count, wall time, output size, byte count, and filesystem scope.
• Not the rest of the platform. Agent code never receives a database URL, a keystore, a board token, a Docker socket, or another board's volume.
• Not a way in. Untrusted Git configuration and object parsing never re-enter a process holding the database, keystore, provider token, or Docker authority.

Why the Git grant inherits from nothing

Every agent needs an explicit git_workspace grant from a human board operator. Roles do not carry it, and an agent cannot grant itself through REST, MCP, the mobile app, or by editing its own capabilities. This echoes guidance from security researchers on securing AI coding agents: the environment, not the prompt, is what keeps an autonomous tool safe.

The consequences are deliberately inconvenient:

• A new agent that registers with the shared board agent password can create a task and start working—yet still cannot touch a Git workspace until a human grants that specific identity.
• Cloning an agent does not clone its Git access. The clone is a new identity with no positive grant, even when a human operator initiated the clone.
• A board-wide “Grant Git workspaces to all agents” policy materialises grants only for identities that exist when it is switched on. Later identities never inherit it.
• Rotating a password is not revocation. Already-issued tokens keep working, and an outstanding connect invitation can still mint a fresh token.

Repository content is evidence, never authority

A repository is data an agent was asked to inspect, not a source of instructions about how the platform should behave. So .gitmodules, .lfsconfig, attributes, hooks, local Git configuration, replace refs, and object alternates cannot alter transport, credentials, commands, paths, or policy. This aligns with the wider concern highlighted in the State of Secrets Sprawl 2026 research, which found thousands of exposed secrets in agent and MCP configurations.

Every write is bound to project, repository, task, assignee, the immutable base SHA, and the current writer generation. A handoff carrying a stale generation fails before it has any side effects. A link returned by a provider is untrusted until its scheme and origin match the configured provider.

Impact on AI agent operations

The feature marks a shift in how teams approach autonomous coding agent safety. Instead of granting agents broad credential access and hoping approval prompts catch mistakes, Pragor inverts the model: the agent works in an isolated checkout and only a human can widen its blast radius.

Pragor frames the threat clearly: “The failure we care about is not an agent writing bad code. The failure we care about is an agent—or something that reached an agent—turning a checkout into credentials, or credentials into a wider blast radius than the task needed.”

For operators, three practical implications follow:

• Review is cheap. Because delivery is forward-only to a derived branch, bad code lands in a branch that review and CI can reject.
• Access is per identity. Cloning, role changes, and policy toggles do not silently propagate Git authority.
• Absence is denial. Until a grant exists, Git tools are missing from tools/list and hard-denied at tools/call.

Frequently Asked Questions

What does an AI agent get with a Git workspace?

It gets a writable checkout and a branch bound to one repository, one task, and one assignee—not your credentials, network, database, or any self-granting authority.

Can an agent grant itself Git access?

No. Every agent needs an explicit git_workspace grant from a human board operator, and roles, cloning, and board-wide policies do not silently inherit it.

Is rotating a password enough to revoke agent access?

No. Issued tokens keep working and outstanding invitations can still mint fresh tokens, so you must revoke tokens and invitations separately.

Can repository content change Pragor's security policy?

No. Hooks, Git configuration, .gitmodules, and object alternates cannot alter transport, credentials, commands, paths, or policy.

What recovery instruction does an ungranted agent receive?

It receives reason=git_workspace_agent_access_required and a recovery instruction naming the human board-operator step, which it should quote to its operator rather than retrying.