Resources and Security Officer

Resources describe the external systems a venture can use, such as source control, cloud services, hosting, analytics, communication, and data systems. The Security Officer flow turns an approved resource request into the narrowest practical access for one workflow or chat context.

SECURE RESOURCE PATH

Approved context becomes scoped runtime access

1. 01

   Register

   Save the external system and secure credential.

2. 02

   Approve

   Select only the resources required by the task.

3. 03

   Provision

   Security Officer prepares narrow, expiring access.

4. 04

   Use safely

   The workload receives protected programmatic access.

Prepare a resource

Before a workflow can use an external system:

1. Add the system under the venture's Resources.
2. Store its credential through the secure credential flow.
3. Verify the resource identity, provider, and intended use.
4. Include the resource when launching or scheduling work that needs it.

Resource metadata can be shown to an agent, but the saved secret is not placed in the model conversation. Never put a secret in a resource description, task, chat message, escalation, URL, or general metadata field.

Pre-authorize access

Selecting resources at launch defines the boundary for that work. The agent can discover and request only resources approved for its context. Mentioning a different system in a prompt does not expand access.

Use a narrow resource selection:

• include only the repository, project, environment, or service needed;
• separate production resources from development resources;
• avoid broad organization credentials where a project credential exists;
• review recurring schedules when a resource or credential changes.

Retries preserve the original resource context. If the required resource has changed, start a new run with the correct selection instead of trying to widen the old run through chat.

How provisioning works

When an authorized agent needs a resource, it submits a reason and requests access. Provisioning can take time, so the workflow waits for a completed or failed result before using the provider.

The Security Officer attempts to:

• minimize permissions for the stated task;
• apply an expiry when the provider supports it;
• deliver the credential programmatically rather than in prose;
• isolate reuse to the same workflow or chat context;
• record non-secret audit evidence.

If a provider cannot produce sufficiently narrow access, provisioning can fail closed. Resolve the provider permissions or create a safer credential instead of pasting the broad source secret into the task.

Credential handling

Provisioned credential material is encrypted while stored and delivered to the workload through a protected runtime path. The agent receives a reference that the required program can use; it should not print, summarize, or persist the secret.

Audit evidence can include the resource, requester, workflow or chat, reason, scope description, time, expiry, warnings, and outcome. It must not include the plaintext credential.

Operate the workflow

For a venture owner or operator:

1. Register the external system and secure credential.
2. Select only the resources required by the workflow.
3. Confirm the resource badges before launch.
4. Monitor the run while access is prepared.
5. If access fails, review the safe failure reason and source credential health.
6. Correct permissions or narrow the request, then retry or relaunch as the workflow permits.

Troubleshoot access

Symptom	Check
Resource is not offered at launch	Venture selection, resource status, provider type, and your role.
Agent cannot see the resource	It was not included in that workflow's approved resource context.
Provisioning fails	Source credential health, provider permissions, expiry, and whether narrower access is possible.
Provider rejects the action	The provisioned scope may be too narrow, expired, rate-limited, or blocked by provider policy.
Retry still uses old access	The run retained its original resource context; relaunch with the intended selection.

If support is required, send the venture, workflow ID, resource name (not its secret), timestamp, and safe failure message.

What to expect

• Least-privilege quality depends on the external provider's credential and permission model.
• Resource relationships can make a related credential available when that relationship and the parent resource were approved.
• Access prepared for one workflow or chat is not automatically reusable by another.
• Removing or rotating a source credential can affect new requests and active work that has not yet obtained access.