Neo's permissions model

This page is the canonical reference for Neo’s permissions model: what Neo can do, which identity it acts as on each surface, what constrains it, and how to scope it down. If you are a security reviewer or platform admin working out what Neo can do, as whom, and how to constrain it, start here.

The core invariant

Neo acts on behalf of the user invoking it, and Neo can only do what that user could do themselves.

• Neo operates within the acting user’s role-based access control (RBAC) entitlements and cannot perform actions that user couldn’t perform.
• No privilege escalation: Neo never gets more access than the user has, only the same or less.
• Tasks are private to the user who created them. That user can share a task with the rest of the organization as a read-only link: viewers see the conversation but cannot act through it, and any stack or resource it links to still enforces the viewer’s own RBAC.

The rest of this page describes which user Neo acts as on each surface, the ceiling that user’s RBAC sets, and the controls that narrow it further.

Execution identity per surface

Neo is one agent reachable from the surfaces below. Whichever surface starts a task, the task runs as a specific Pulumi identity:

These identities govern what Neo does in Pulumi Cloud. Writes to your version control provider are a separate matter: Neo authenticates as the shared app installation for its VCS interactions no matter which surface started the task (see VCS identity per provider).

Because a task’s Pulumi RBAC is evaluated at execution time, it never runs with stale permissions: if the acting user is deactivated or loses access, the task loses that access immediately, including in the middle of a running task.

What Neo can access, per Pulumi Cloud area

Neo’s access ceiling is the acting user’s RBAC. Within that ceiling, Neo reads broadly — it leans on the Pulumi Cloud APIs heavily to retrieve and search your infrastructure — and it makes changes two ways: through code and pull requests for anything you manage in IaC, and directly through the Pulumi Cloud APIs for anything you don’t. Managing your Pulumi estate in IaC is what routes Neo’s changes through code review.

ESC, secrets, and downstream cloud access

Neo inherits the acting user’s ESC access. If the user can open an environment (the environment:open permission), so can Neo — which means Neo can decrypt that environment’s secrets and use any dynamic cloud credentials it mints. If an environment brokers OIDC credentials to an AWS, Azure, or Google Cloud account, Neo can assume those roles and operate in that cloud account, exactly as the user could.

This has two consequences worth stating plainly:

• “Read-only” is scoped to Pulumi Cloud, not to your cloud accounts. Read-only mode blocks writes in Pulumi Cloud and instructs Neo not to make modifications, but it does not technically prevent Neo from opening ESC environments or reaching the cloud accounts those environments unlock. Treat read-only as “no Pulumi Cloud mutations,” not “no side effects anywhere.”
• Handling of secret values. ESC secrets carry a weaker guarantee than MCP integration credentials, which are never exposed to the language model at all: an ESC-sourced secret value can reach the model if a task reads it directly. Three things limit that exposure. Neo is instructed never to run pulumi env open or pulumi env get --show-secrets, and where possible it moves secret values without reading them into context — for example, redirecting a cloud CLI’s output straight to a file. Pulumi then scans the events a task produces for credential patterns and replaces what it detects with [REDACTED] before storing them, so detected values stay out of task history, shared task views, and Slack and pull request output. Treat that scan as defense in depth rather than a guarantee: it matches known credential shapes, not every string a secret value could take. Neo’s models run through Amazon Bedrock, which does not retain prompts or completions, and an idle task’s runtime session is torn down — the next turn rebuilds context from the stored, redacted history.

To constrain what Neo can reach, scope the acting user’s RBAC and the ESC environments they can open. Prefer read-only cloud roles in ESC environments and broaden them deliberately. For the environments that unlock the most, ESC open approvals put a reviewer in front of every attempt to open them — including Neo’s, since Neo opens them as you.

Permission mode and approval mode

Neo has two independent axes of control. Do not conflate them:

Approval-mode gates:

• Review mode: Neo requires approval before running pulumi preview, running pulumi up, and opening a pull request.
• Balanced mode: Neo requires approval only before running pulumi up.
• Auto mode: Neo does not require any approvals.

Plan Mode is a separate, pre-execution control: it makes Neo research and agree on a plan with you before it acts, and it composes with any permission or approval mode.

What triggers an approval prompt

Approval mode gates the Pulumi actions above — pulumi preview, pulumi up, and opening a pull request. It’s important to understand what it does not gate.

By design, Neo investigates autonomously. During the investigation phase it reads state, opens ESC environments, and reaches the cloud accounts, clusters, and integrations it has access to without prompting for each action — an explicit tradeoff to avoid approval fatigue on the many small reads a real investigation requires. Approval prompts apply to the Pulumi write actions listed above (and to sensitive writes Neo surfaces for confirmation), not to bare read access.

The practical implication: if you need Neo to stay within a boundary, set that boundary with permissions (the user’s RBAC and the ESC environments they can open), not by relying on approval prompts to catch every access.

The control inventory

Every lever that shapes what a Neo task can do, and who sets it:

For scheduled automations, settings resolve in this order: the per-automation setting, then the org-level default, then the built-in fallback (auto approval and read-only permissions).

Org-level defaults for permission and approval mode set the starting point for new tasks; a user can override them per task.

CLI integrations are a distinct, admin-controlled capability: an organization admin points a CLI at an ESC environment, and every task in the organization is then offered that integration unless the user turns it off for the task. Being offered an integration is not the same as being able to use it. Neo invokes the CLI with pulumi env run, as the acting user, so the integration only works for users who can open the backing environment — for anyone else, the call fails with a permission error rather than handing over the environment’s credentials. Connecting an integration doesn’t widen anyone’s access; it makes an environment the user could already open convenient for Neo to reach. Scope each integration’s ESC environment to what Neo needs — prefer a read-only cloud role and broaden it deliberately.

VCS identity per provider

Neo’s version control writes do not run as you. Neo authenticates as the shared app installation for its VCS interactions — opening pull requests, pushing commits, commenting, posting checks. Creating a repository is the exception: that runs as your connected individual account, which is why it needs individual access.

Learn more

• Role-based access control — the permission model Neo inherits
• Least-privilege access — scoping down what a user, and so Neo, can do
• Pulumi ESC — environments, secrets, and dynamic credentials
• ESC approvals — review gates on opening and updating an environment
• Tasks — Plan Mode and approval modes in depth
• Automations — scheduled tasks and their defaults
• Integrations — MCP and CLI integration credentials
• Version control — per-provider VCS setup