Access control

Enterprise policy, enforced at the point of access.

Enforce task-specific access policies within existing enterprise permissions. MarcoPolo applies controls as agents use data across connected systems.

Review access controlsSee a policy example
Governed data access runtime

Scope access to the task.

Agents choose data and actions as a task unfolds. Permission to connect to a system does not define which records or fields an agent should use, or what it may change. MarcoPolo enforces task-specific restrictions within enterprise permissions on each request.

Preserve enterprise authority

Access begins with the authority supplied for the request. Source-system permissions continue to constrain what can be accessed and which operations can be performed.

access controllive
Request · claude.ai for amina@acmeread customer accounts
evaluated on this request
MarcoPolo runtime · policy
  • Identityamina@acme · authenticatedallow
  • Source permissionsalesforce · sales_readallow
  • Beyond the user's rolesalesforce · admin objectsdeny
only what the task needs
access starts from the user's authorityenforced

Control records, fields, and actions

Restrict which records and fields an agent can read and which operations it can perform across connected systems. Task policies narrow access within enterprise permissions.

access controllive
Request · svc:agent-42 for amina@acmeread accounts, update vendor bank details
evaluated on this request
MarcoPolo runtime · policy
  • Enterprise permissionamina@acme · finance_readallow
  • Recordsaccounts · region = Westallow
  • Fieldstax_id, bank_accountnarrowed
  • Actionupdate payments.vendordeny
only what the task needs
12 records · 6 fields · read onlyenforced

Enforce during the request

Apply access controls when agents use connected systems. Restrictions belong at the access boundary, rather than relying on an agent to follow instructions in a prompt.

runtime · enforcementlive
# Checked on the request, not in the prompt.▸ read    accounts               allow▸ read    accounts.tax_id        narrowed▸ read    accounts.bank_account  narrowed▸ update  payments.vendor        deny# The agent gets only what the task needs.▍
How access is constrained

Three boundaries. Every request.

A connection grant, source permissions, and a task policy answer different questions. A request must stay within all three as the agent chooses its next step.

  1. Which connections can this caller use?

    Establish the user or service account making the request and the connections it owns or has been granted. Signing in identifies the caller; it does not grant access to every source.

  2. What does the source permit?

    The source enforces the permissions attached to the credentials used for that connection. With shared credentials, those are the shared account’s permissions; any additional user restrictions must be enforced separately.

  3. What does this task require?

    Authorized teams configure task restrictions within those boundaries. MarcoPolo applies them as requests run, limiting the records, fields, and actions available. A task policy can narrow access; it cannot grant new source authority.

Illustrative task policy

Investigate a payment. Keep changes out of scope.

Task
Find why these payment records don’t match the ledger.
Authority
A payments analyst, within their assigned business unit.
Allowed
Read transaction references, amounts, and dates for the assigned business unit.
Blocked
Read other business units’ records, change payment instructions, or update the ledger.

Granting access to the payment and ledger connections does not authorize every operation they support. The investigation’s restrictions continue to apply on each request.

Define the access your first task needs.

Bring the caller identity, source permissions, and the records and actions the task should be allowed to use.

Review access controlsSee a policy example