CI/CD and PaaS Security: Preventing Credential Theft

The Pipeline is the Perimeter: A CI/CD and PaaS Credential-Hardening Guide

Engineering teams often invest heavily in hardening production VPCs and application firewalls while leaving high-privilege credentials exposed inside build pipelines and platform configuration stores.

In October 2026, two security disclosures highlighted the systemic risk of treating build and deployment infrastructure as implicitly trusted. First, cloud deployment provider Railway disclosed an intrusion into its build infrastructure (occurring between October 18 and October 21, 2026) that allowed an attacker to access internal CI environments and decrypt a subset of customer secrets (Railway Final Incident Report, Nov 10, 2026). Days later, on October 30, 2026, container PaaS provider Northflank issued a security advisory following a platform security incident, instructing customers to work from the assumption that stored environment variables could have been decrypted and to rotate credentials immediately (CSA Research Note on Northflank Advisory, Nov 2, 2026).

Rather than exploiting flaws in customer application code, these incidents involved attacks or suspected exposure within the underlying delivery and hosting plumbing: build isolation boundaries, internal CI credentials, and environment variable stores.

This article is a CI/CD and PaaS credential-hardening guide informed by those recent incidents, not a forensic reconstruction of undisclosed vendor exploits. It examines what the public disclosures actually tell us about control-plane blast radius, asks why static credentials exist inside delivery pipelines at all, and provides concrete, validated architectural patterns to eliminate or bound credential risk.

---

Scope and Assumptions

The guidance below applies across two distinct operational models:

1. Managed PaaS Environments (e.g., Railway, Northflank, Render, Fly.io, Vercel): The provider manages the underlying compute, build orchestration, and secret storage. Customers cannot modify host kernels or runner network fabrics and must focus on secret elimination, credential scoping, external API spend limits, and rotation readiness.
2. Self-Hosted and Cloud-Native CI/CD (e.g., GitHub Actions with AWS OIDC, self-hosted Kubernetes runners, GitLab Runners on EC2): The customer controls IAM trust policies, repository and environment governance, runner sandboxing, network egress, and KMS encryption contexts.

Policy examples focus on AWS IAM, AWS KMS, and AWS Secrets Manager integrated with GitHub Actions, though the architectural principles map directly to Google Cloud IAM/KMS and Azure RBAC/Key Vault.

---

1. Incident Analysis: Confirmed Findings, Operational Blast Radius, and Architectural Inference

To design effective controls, we must separate confirmed vendor disclosures from general multi-tenant CI/CD risk patterns, and examine what exposure numbers mean in practice.

Confirmed Findings (Railway Disclosure)

Based on Railway's published post-incident reports (Preliminary Report, Oct 22; Final Report, Nov 10):

• Dummy-Account Signups and Probing (Oct 18 to Oct 20, 2026): The attacker's initial dummy-account signups began on October 18, 2026, with early unsuccessful attempts. Active probing of the build system began on October 20 at 06:50 UTC.
• Filesystem-Isolation Escape and Build History Access (Oct 20, 2026): On October 20 at 07:28 UTC, the attacker exploited an undisclosed flaw in the build infrastructure to escape filesystem isolation on the underlying host VM, reading host files and obtaining an internal build credential. Later that day, between 13:50 and 15:30 UTC, the attacker used that access to read the stored histories of 353 builds (including sealed variables).
• Internal CI Pivot and Key Decryption (Oct 21, 04:42 to 07:14 UTC): Using credentials that provided access to internal CI environments, the attacker retrieved encrypted artifacts and decrypted per-environment keys from 04:42 UTC until Railway disabled the compromised credential at 07:14 UTC.

Interrogating the Blast Radius: Exposure Ceiling vs. Confirmed Compromise

Railway estimated that up to approximately 100,000 workspaces (~1.85% of total workspaces) fell within the range where environment variables could potentially have been decrypted. That figure is an exposure ceiling, not a count of confirmed compromises. Railway separately confirmed decrypted linked-account tokens (such as BYOK agent keys and GitHub OAuth tokens) for 1,852 users. Additionally, Railway estimated unauthorized usage at approximately $740,000 across upstream AI providers; this was not necessarily an amount ultimately charged to customers, as Railway coordinated directly with AI providers to refund unauthorized spend and committed to backstopping unrefunded balances from its own funds.

The distinction between theoretical exposure and confirmed misuse matters, but the larger ceiling still represents a significant operational blast radius:

• Operational Reality for Defenders: For an engineering team whose workspace sits inside that ~100,000-workspace exposure window, "unconfirmed decryption" requires the same immediate response as confirmed compromise. Defenders cannot wait for positive forensic proof of downstream key replay before rotating credentials.
• The Core Architectural Lesson: The most important takeaway from the timeline is not how the initial container or VM boundary failed, but why a credential reachable from internal CI infrastructure held sufficient authority to decrypt per-environment keys across tens of thousands of workspaces. Notably, in its post-incident remediation, Railway specifically re-architected this boundary so that no service other than its dedicated secrets service can access keys that decrypt data encryption keys (DEKs), restricting each calling service to decrypting only the specific credentials it requires to operate.

Qualifying the Northflank Advisory (Oct 30, 2026)

Public information about the Northflank incident remains less detailed than Railway's disclosure. In its October 30 advisory, Northflank instructed customers to assume stored environment variables could have been decrypted and to rotate them immediately (CSA Research Note). It is included here as a credential-rotation and provider-trust case study, not as a technically equivalent post-mortem.

Architectural Inference: Common Multi-Tenant CI/CD Risk Paths

Railway did not publicly disclose the exact low-level vulnerability used to escape filesystem isolation. Across self-hosted and multi-tenant CI/CD systems generally, sandbox escapes and credential pivots typically follow three technical risk paths:

1. Container or Runtime Breakout: Untrusted build steps may abuse an exposed host Docker socket (/var/run/docker.sock), excessive Linux capabilities (such as CAP_SYS_ADMIN), or shared-kernel vulnerabilities to access the host filesystem. (Note: These are common industry failure modes, not confirmed mechanisms of the Railway intrusion.)
2. Host-Level Credential Harvesting: Once a build process reads host files or instance metadata (169.254.169.254), it can harvest node-level IAM role credentials, kubelet certificates, or long-lived worker tokens.
3. Broad Secret-Store Authorization: If worker nodes or internal CI tools authenticate to secret stores using shared service identities rather than job-specific cryptographic attestations, a compromised token can request secrets far beyond the scope of a single build.

---

2. Three Common Blind Spots in Delivery Pipelines

Blind Spot 1: Single-Role Pipelines and Unnecessary Pipeline Secret Access

A common failure pattern is assigning a single, broad IAM role to an entire CI/CD workflow. When the same runner that compiles untrusted pull-request code and installs third-party npm or PyPI dependencies also holds permissions to read production secrets or modify cloud state, an attacker who compromises a build script does not need to escalate privileges; the build environment already possesses deployment authority. Even worse, teams frequently grant the deployment runner permission to read application runtime secrets (such as Stripe or OpenAI keys) simply to inject them into configuration files during deploy, placing the CI/CD pipeline directly in the secret data path.

Blind Spot 2: Unscoped Decryption Authority on Worker Nodes

Encrypting secrets at rest provides limited protection if any active worker node or internal CI service can freely decrypt them. When CI nodes hold static decryption keys or broad kms:Decrypt permissions without job-level encryption context checks, compromising a single runner exposes every secret accessible to that role.

Blind Spot 3: External API Key Replay Outside Your Network

An observed pattern highlighted across recent PaaS and CI/CD security advisories is compute arbitrage: harvesting API keys for AI inference providers (such as OpenAI, Anthropic, and OpenRouter) to feed illicit key-resale pipelines or Model-as-a-Service distillation workloads (Railway Preliminary Report; CSA Research Note on AI Key Resale Pipelines).

The visibility gap: When an attacker exfiltrates a third-party SaaS or AI API key, they typically invoke the provider's API directly from external infrastructure. Because those requests do not originate from your VPC, your internal network monitors (such as AWS VPC Flow Logs or host-based EDR agents) will not observe the fraudulent API calls. Unless you enforce hard spend limits and monitor usage velocity inside the third-party provider's console, abuse can continue unnoticed until rate limits or billing alerts trigger.

---

3. Hardening Guide for Managed PaaS Users

When a security incident occurs within a managed PaaS provider's build or control plane, customer-side repository hygiene alone cannot prevent the exposure of variables stored on the platform. You can, however, reduce the value and blast radius of any stored credential:

1. Treat Platform Environment Variables as Semi-Trusted: Avoid storing root cloud credentials, organization-wide admin tokens, or unscoped IAM user keys in PaaS environment stores.
2. Eliminate Static Cloud Keys via Federation or Proxies: Where supported, use OpenID Connect (OIDC) workload identity federation or short-lived session tokens to access AWS, GCP, or Azure resources rather than static AWS_SECRET_ACCESS_KEY values. For AI inference workloads, consider routing requests through a cloud-native gateway (such as AWS Bedrock via federated IAM roles) instead of storing long-lived bearer tokens in PaaS environment variables.
3. Scope Keys Per Environment and Per Service: Provision distinct API keys for development, staging, and production, and separate keys by microservice.
4. Configure Provider-Side Guardrails for AI and SaaS Keys:
5. Hard Spend Caps and Per-Key Budgets: Set strict monthly dollar limits and per-project/per-key budgets in OpenAI, Anthropic, and OpenRouter dashboards.
6. Billing and Velocity Alerts: Configure automated webhook or email alerts at incremental thresholds (for example, 25%, 50%, and 80% of expected daily spend).

7. Client IP Restrictions: Where upstream providers support IP allowlisting, restrict API key usage to the static outbound NAT gateway IPs of your production workloads.

8. Build a Tiered Credential Rotation Playbook: Aim to automate rotation for stateless API keys within 15 minutes using CLI scripts or Terraform. For stateful credentials that cannot be rotated instantaneously without downtime (such as primary database passwords or webhook signing secrets without dual-key support), document a coordinated runbook that uses overlapping secondary credentials to prevent service outages during emergency rotation.

---

4. Defense-in-Depth Playbook for Self-Hosted & Cloud CI/CD

Note on Scope: The following controls are not presented as a reconstruction of Railway's undisclosed exploit. They are a general defense-in-depth playbook for reducing the same classes of trust-boundary and credential-pivot risk in environments you control.

First Question: Can the Secret Be Eliminated from the Pipeline?

Before placing a credential in a PaaS variable store or granting a deploy role access to AWS Secrets Manager, ask two foundational questions:

1. Does the secret need to exist as a static bearer token at all? Determine whether the downstream dependency supports OIDC, workload identity federation (e.g., AWS IAM Roles for Service Accounts / EKS Pod Identity, RDS IAM authentication), short-lived tokens, or a narrowly scoped authenticating proxy. A secret that does not need to exist is safer than a secret protected by a stronger key policy.
2. Does the CI/CD pipeline ever need to read the plaintext secret? Even when a third-party service requires a static API key (such as Stripe or an external LLM API), your CI/CD deployment role rarely needs secretsmanager:GetSecretValue permission. Instead, the deployment role should only reference the secret ARN in the task or pod definition (for example, ECS secrets valueFrom or Kubernetes External Secrets Operator), allowing the production runtime identity to fetch the secret at container startup. Removing GetSecretValue from the CI/CD role entirely prevents a compromised pipeline from reading application secrets.

Control 1: Enforce Stage Separation (Build vs. Deploy)

Split pipelines into separate execution stages with distinct IAM roles:

• Build Role (ci-build-role): Executes in an isolated, ephemeral environment with no access to production secrets or live infrastructure. Its permissions are restricted to compiling code, running tests, signing artifacts, and pushing immutable images to a staging registry.
• Deploy Role (cd-deploy-role): Triggered only after build completion and branch/environment protection checks. It runs on a separate runner identity that pulls verified artifacts and updates the target environment without reading underlying application secrets unless strictly required by the deployment mechanism.

Control 2: Hardware-Protected Keys and Scoped Encryption Contexts

For workflows where a deployment or runtime identity must decrypt a secret, ensure worker nodes never hold raw master decryption keys:

• Managed KMS vs. Dedicated HSMs: Use AWS KMS (which protects root key material within FIPS 140-3 validated hardware security modules managed by AWS) or AWS CloudHSM (which provides dedicated, single-tenant HSM appliances under your direct control; verify specific regional FIPS validation certificates on the AWS Compliance portal for regulated workloads).
• Scoped KMS Encryption Contexts: When storing secrets in AWS Secrets Manager, enforce KMS policies that restrict decryption to specific secret ARNs (kms:EncryptionContext:SecretARN) and require requests to pass through the Secrets Manager service (kms:ViaService) (AWS Secrets Manager Encryption Documentation).
• Ephemeral Memory Mounting (tmpfs) with Process Hygiene: Injecting secrets into an in-memory filesystem (tmpfs or /dev/shm) rather than persistent disk reduces the risk of secrets surviving on unencrypted block storage or disk snapshots. However, tmpfs alone does not prevent exposure if a compromised process reads /proc/[pid]/environ, inspects process memory, prints variables to build logs, or passes secrets via command-line arguments (ps). Combine memory mounts with strict process isolation, disabled core dumps, and log scrubbing.

Control 3: Stronger Compute Isolation and Layered Egress Controls

• MicroVM or User-Space Kernel Isolation: For self-hosted multi-tenant builds, prefer Firecracker microVMs or gVisor over standard shared-kernel Docker containers to raise the cost of host breakout.
• Defense-in-Depth Egress Filtering: Standard hostname-based iptables rules are unreliable for dynamic FQDN filtering because iptables resolves hostnames only when rules are loaded, failing when CDN IP addresses rotate. Instead, route build runner traffic through an egress proxy (such as Squid) or enforce Kubernetes CNI policies (such as Cilium toFQDNs) paired with firewall rules that block direct outbound connections to raw IP addresses.
• Important Caveat on FQDN Filtering: Egress filtering by domain name is a risk-reduction layer, not a complete guarantee against exfiltration. If a build requires access to github.com, npmjs.org, or s3.amazonaws.com, an attacker executing code inside that build can still exfiltrate secrets to attacker-controlled repositories, gists, or buckets on those permitted domains, or attempt DNS tunneling if DNS resolution is not strictly controlled. Pair egress filtering with short-lived credentials and post-build audit logging.

---

5. Validated AWS OIDC Guardrails, KMS Key Policies, and Detection

Step 1: Lock Down the GitHub Actions OIDC Trust Policy

Overly broad OIDC trust policies (such as wildcard repository rules like "repo:my-org/*") allow any branch or pull request in an organization to assume sensitive roles. Restrict the role trust policy using StringEquals on the sub claim so only jobs running in the protected production environment of a specific repository can assume the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StrictGitHubActionsOIDCDeployOnly",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:org-name/payment-service:environment:production"
        }
      }
    }
  ]
}

Why the sub Claim Is Decorative Without GitHub Governance:

The sub condition above is meaningful only when paired with GitHub environment protection rules, required reviewers, deployment-branch restrictions, and repository branch protection. When a GitHub Actions job declares environment: production, GitHub formats the sub claim with :environment:production. If the production environment in GitHub repository settings has no deployment-branch restrictions or required approvals configured, any workflow run in that repository referencing environment: production will receive a valid OIDC token matching that exact sub claim. To make this control effective:

1. Configure Deployment branches on the production GitHub Environment to allow only main (or verified release tags).
2. Enable Required reviewers on the production environment so a human approval gate precedes token issuance.
3. Enforce branch protection on main (requiring pull request reviews, status checks, and CODEOWNERS approval on .github/workflows/) and opt into GitHub's immutable repository ID subject claims where supported.

Step 2: Scope the IAM Role Policy with SecretARN Encryption Context

For the identity that requires secret decryption (ideally the runtime task role, or a tightly gated deploy role where runtime secret injection is unavailable), scope the attached IAM policy using kms:EncryptionContext:SecretARN and kms:ViaService. Per the AWS Secrets Manager encryption documentation, Secrets Manager passes the full secret ARN (including the 6-character random suffix) in the SecretARN encryption context key during every kms:Decrypt call:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGetSpecificSecretValueOnly",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/payment-service/api-keys-AbCdEf"
    },
    {
      "Sid": "AllowKMSDecryptOnlyViaSecretsManagerForSpecificARN",
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws:kms:us-east-1:111122223333:key/12345678-1234-1234-1234-123456789012",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com",
          "kms:EncryptionContext:SecretARN": "arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/payment-service/api-keys-AbCdEf"
        }
      }
    }
  ]
}

Step 3: Pair with the Companion Customer-Managed KMS Key Policy

In AWS KMS, an IAM identity policy is evaluated only if the KMS Key Policy permits it. Beyond the standard account-root delegation statement, you can add a defense-in-depth Deny statement directly to the CMK's Key Policy so that non-admin principals in the account are blocked from calling kms:Decrypt directly against the KMS API, forcing all decrypt operations through Secrets Manager:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMUserPermissionsWithAdminSeparation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "DenyDirectDecryptOutsideSecretsManager",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com"
        }
      }
    }
  ]
}

AWS Pre-Deployment Validation Checklist:

• Verify the 6-Character Suffix: Ensure the SecretARN in both Resource and kms:EncryptionContext:SecretARN includes the exact 6-character random suffix appended by Secrets Manager (for example, -AbCdEf). If secrets are frequently destroyed and recreated with new suffixes via infrastructure-as-code, test with StringLike and -?????? in staging first.
• Verify Write/Rotation Requirements: The policy above is strictly read-only (GetSecretValue + kms:Decrypt). If your deployment workflow creates, updates, or rotates secrets (CreateSecret, PutSecretValue, UpdateSecret), you must also permit kms:GenerateDataKey on the CMK.

Detection and Containment Considerations

1. CloudTrail IP and Network Boundary Detection (Architecture-Dependent):
2. Self-Hosted Runners: Whether you can enforce or alert on IP and VPC boundaries depends on your specific runner and network routing architecture. If your self-hosted runners access AWS APIs through a public NAT Gateway with static Elastic IPs, you can alert on (or restrict via aws:SourceIp) calls originating outside those NAT CIDRs. If your runners operate inside a private subnet using AWS PrivateLink interface VPC endpoints for Secrets Manager and STS, aws:SourceIp will reflect private VPC addresses rather than public NAT IPs; in that topology, scope access using aws:SourceVpce or aws:SourceVpc conditions instead.

3. GitHub-Hosted Runners: Standard GitHub-hosted runners use dynamic, shared cloud IP ranges that change frequently, making static CIDR allowlisting impractical unless you use GitHub Enterprise larger runners with static IP configurations or private networking integration. For standard hosted runners, monitor CloudTrail for anomalous API call volume, off-hours role assumptions, or unexpected sub claims.

4. Containment via Session Revocation:

5. Attaching an inline Deny policy with an aws:TokenIssueTime (DateLessThan) condition to a compromised IAM role is a useful containment mechanism to block subsequent authorization for temporary STS credentials issued before a specific UTC timestamp.

6. Operational Caveat: Policy updates are subject to IAM propagation delays and do not terminate active network connections already established using downstream application keys. Teams should test session revocation behavior in a staging environment beforehand to verify how it interacts with their specific federation method.

---

6. Threat Model: Why Does This Credential Exist?

Hardening KMS policies and runner sandboxes treats the symptom of secret exposure; threat-modeling credential existence addresses the root cause. Before storing any secret in a PaaS environment or CI/CD secret manager, evaluate it against six architectural questions:

1. Why does the workload need this credential at all?

Many static credentials exist out of habit rather than technical necessity. Audit every environment variable in your deployment configuration. Legacy API tokens for deprecated analytics tools, unused staging webhooks, and overly broad service-to-service keys frequently sit dormant in workspace variables, waiting to be harvested during a control-plane breach.

2. Can the provider support workload identity or short-lived credentials?

Static cloud keys (AWS_SECRET_ACCESS_KEY, GCP service account JSON files) and static database passwords should be systematically replaced with cryptographic identity federation:

• Cloud APIs: Use OIDC federation (sts:AssumeRoleWithWebIdentity) for CI/CD jobs and EKS Pod Identity / ECS Task Roles for runtime workloads.
• Databases: Replace static PostgreSQL/MySQL passwords in environment variables with IAM database authentication (rds-db:connect), issuing tokens valid for 15 minutes.
• AI Inference: Where possible, invoke foundation models through cloud-authenticated gateways (such as Amazon Bedrock or Google Vertex AI using short-lived IAM credentials) rather than managing long-lived bearer keys from standalone API providers.

3. Can the credential be scoped to one service, environment, operation, or endpoint?

If a static third-party API key cannot be avoided, strip it to its minimum viable authority:

• Never share an API key between payment-service and notification-service, or between staging and production.
• Use fine-grained personal access tokens or service-specific restricted keys (for example, a Stripe restricted key permitted only to create payment intents, with zero permission to issue refunds or read customer payout data).

4. Can the application retrieve credentials at runtime instead of exposing them during builds or deploys?

A build container compiling TypeScript or building a Docker layer almost never needs access to production API keys. Even at deployment time, the CI/CD runner should pass secret references (ARNs or Vault paths) to the target orchestrator rather than fetching plaintext values into the runner's memory and passing them as cleartext strings in deployment payloads.

5. Can the deploy role broker a temporary credential rather than retrieve a long-lived secret?

When a deployment pipeline must interact with a downstream system (such as running database migrations or invalidating a CDN cache), design the deploy role to request a single-use, short-lived token (via OIDC exchange, HashiCorp Vault dynamic secrets, or GitHub App installation token minting) that expires as soon as the deployment job finishes, rather than pulling a static master key from Secrets Manager.

6. What is the maximum financial and operational damage if the credential is stolen?

Assume the credential will be decrypted by an external attacker at 03:00 UTC on a Sunday. Calculate the worst-case upper bound:

• If an AI inference key has no hard monthly dollar cap, the financial blast radius may be bounded only by the provider's account limits, rate limits, billing controls, and the payment methods attached to the account.
• If an API key is capped at $200/month, restricted to two outbound NAT IPs, and scoped to a single non-destructive endpoint, a control-plane compromise becomes a manageable operational event rather than a severe financial incident.

---

7. Summary Checklist: Pipeline and PaaS Credential Hardening

1. Eliminate Unnecessary Secrets First: Replace static cloud keys, database passwords, and standalone AI bearer tokens with OIDC workload identity, IAM DB auth, or cloud-authenticated model gateways wherever supported.
2. Remove CI/CD from the Runtime Secret Path: Pass secret ARNs by reference into ECS/Kubernetes runtime definitions so build and deploy runners never call secretsmanager:GetSecretValue on application secrets.
3. Pair OIDC sub Claims with GitHub Governance: Lock sts:AssumeRoleWithWebIdentity to environment:production and enforce GitHub Environment deployment-branch rules, required human reviewers, and CODEOWNERS workflow protection.
4. Enforce and Test KMS Encryption Contexts: Where secret decryption is required, bind kms:Decrypt to exact kms:EncryptionContext:SecretARN values and kms:ViaService across both the IAM policy and the KMS key policy, validating in staging before rollout.
5. Bound External API Blast Radius: Configure hard dollar spend limits, per-key budgets, velocity alerts, and IP allowlists on all third-party AI and SaaS credentials.
6. Layer Compute and Egress Controls: Isolate self-hosted builds with microVMs or gVisor and filter outbound traffic via FQDN proxies (Cilium/Squid) plus raw-IP drops, recognizing that allowed domains still require least-privilege credential scoping.
7. Prepare a Tiered Rotation Runbook: Automate 15-minute CLI/Terraform rotation for stateless keys and maintain dual-key rollover procedures for stateful dependencies.

---

Author Note: Yashvi Kothari is a Cloud Operations and DevSecOps engineer focusing on cloud infrastructure resilience and security architecture.