Circleci Access Artifacts
To handle circleci access artifacts, you configure a storage step in your build workflow. Then, your team reads those saved files through the web dashboard or an API key. Most engineering teams set up this flow to save test reports, logs, and compiled packages. Still, teams often share broad API tokens or give every developer full project permissions. When permissions are too wide, anyone with a token can pull sensitive build outputs. How circleci access artifacts work in a build pipeline Dur
CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To handle circleci access artifacts, you configure a storage step in your build workflow. Then, your team reads those saved files through the web dashboard or an API key. Most engineering teams set up this flow to save test reports, logs, and compiled packages. Still, teams often share broad API tokens or give every developer full project permissions. When permissions are too wide, anyone with a token can pull sensitive build outputs.
How circleci access artifacts work in a build pipeline
During a build run, a job creates files inside a local working folder. When the main task finishes, a dedicated step uploads chosen files to cloud object storage. The platform ties those saved files to that specific job and build number. Users can log in to the web app and view files in their browser. Automated scripts can also fetch these files by sending an API request with a token.
Access rules depend on your source code host and your project visibility settings. If a code repo is public, anyone can read the build outputs without logging in. For private repos, a user must have read permissions on the linked code repo. Personal API tokens inherit the full permissions of the user who created them. Project tokens offer narrower scope, yet they still grant read rights to all saved files.
What native artifact permissions solve and what they miss
Native project permissions do a good job of blocking outside users from private builds. By linking roles to your code host, the platform keeps basic team access simple. When someone leaves the company, removing their repo role also cuts off their build access. This setup handles basic login checks for standard software builds.
Still, native settings only check who logs in, not what happens inside the files. Build logs and test outputs often hold leaked secrets, database dumps, or customer data. For instance, an integration test failure might print emails, phone numbers, or card numbers. Once a user or script passes the login check, they can download everything. The platform does not inspect file contents or filter sensitive fields during a download.
Static API tokens create another big risk for operations and security teams. Engineers often place personal tokens into external scripts to pull build packages onto servers. Those tokens stay valid until someone deletes them by hand. If a token leaks, an attacker can pull every artifact across all linked projects. Native controls cannot require peer approval for a single download or redact data in flight.
CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Reducing risk when teams store and fetch build outputs
To lower risk, teams should limit what data enters the artifact folder first. Make sure test runners scrub national IDs, emails, and secrets before writing log files. Split build jobs so public assets and sensitive internal reports do not share one project. Rotate API keys on a regular schedule and remove unused project tokens right away.
You should also audit who pulls build files and where those files go next. When developers need to inspect production build outputs or run scripts, check every request. Adding runtime controls lets your team approve sensitive actions and mask data in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do automated scripts download saved files from a private build?
Scripts send an HTTP request to the platform API using a valid token. The request queries the specific job number to get a list of file URLs. The script then follows the storage redirect while keeping the authorization header attached.
Who can view files saved during a workflow run?
For private projects, anyone with read rights on the linked code repo can view them. For open source projects, the saved files are visible to the public by default. Users with a valid personal or project API key can also fetch them.
Why do sensitive details end up in build outputs?
Test suites and crash reporters often dump full memory states or raw database rows. When a test fails, the runner writes those details straight into the saved log file. Without data masking, anyone who downloads the test report gets that raw data.