Skip to main content
For Starfort to read sources and write outputs, it needs a way into your storage. That access is registered ahead of time as a Storage Connection, per project — without one, batch intake itself is rejected (S3_CONNECTION_NOT_CONFIGURED — see Batch errors). Registration and management happen in the console’s settings area, and every registration, change, and deletion is recorded in the Audit Log.

​
What gets registered

Grant the credentials least privilege — read (GetObject) on the source paths and write (PutObject) on the output paths is all it takes.

​
Access keys are encrypted at rest

The secret half of an access key is stored encrypted and is never exposed again by any query after registration.

​
Allowed-target scopes

A job’s two addresses are each checked against the registered allowed targets:
  • src_s3_url must be inside the allowed read scope.
  • tgt_s3_url must be inside the allowed write scope.
If either falls outside the registered scope, intake is rejected and no job is created (S3_TARGET_NOT_ALLOWED). Because delegation is narrowed to a minimum at registration time, the credentials can’t accidentally be used against some other path.

​
Storage types

A Storage Connection has a type, and what gets registered differs by type. The skeleton — per-project registration, scope enforcement, Audit Log coverage — is shared by both. A job’s source and target are resolved against separate Storage Connections — the source address is checked against a connection with read scope, the target address against one with write scope, and the two connections may be of different types (e.g. source on object storage, output on file storage).

​
What changes with the file storage type

File storage is accessed through an area pre-connected to the platform rather than per-request credentials, so the following differ:
  • The connection is a prerequisite. Registering the integration only means something once the link between the customer environment and the platform is in place; registering without a connection leads to intake rejections.
  • An unreachable integration area is distinguished from a missing source. A severed connection can look like “an empty path,” so the execution layer confirms the area’s connectivity before reading the source and before writing the output — and if it isn’t connected, fails the job with a reason distinct from a missing source.
  • Outputs are written only to a confirmed-connected area. A write attempted without a confirmed connection is finalized as a write failure — there is no such thing as a completion without its output.
  • Output file permissions are fixed to pre-agreed values, because the integration only works if the downstream consumer can read the result files.
Per-verdict output rules and inspection limits are identical regardless of storage type. See Output rules & limits.