Procurement-relevant trust claims (what Aikido publicly states)

Aikido (Aikido Security) positions its platform as developer-focused security across code scanning and cloud posture, with additional modules such as pentesting and runtime protection. (aikido.dev)

For vendor risk review and security procurement, Aikido's most frequently cited trust-center claims are:

Source code handling: Aikido states it does not store customer source code after analysis; scans run in temporary environments that are disposed of after analysis. (aikido.dev)
Access model: Aikido states its approach is API-based and agentless (including CSPM), emphasizing read-only access.
Compliance posture: Aikido states it has been examined/attested such that its system and suitability of controls meets AICPA SOC 2 Type II and ISO 27001:2022 requirements.
Ongoing security practices: Aikido states it performs annual external pentests and maintains a bug bounty program (with workflow references to Intigriti on the Trust Center page).
Options for restricted environments: Aikido's pricing materials reference local/on-prem deployment and a "Broker for Internal Apps" to scan/pentest internal apps without exposing them publicly. (aikido.dev)

Source code access & "ephemeral scanning" (what it means in practice)

Aikido's stated model for analyzing repositories

Aikido states that some analysis jobs (e.g., SAST, secrets detection) require a git clone operation, but that it does not store code after analysis. (aikido.dev)

Aikido's Trust Center describes its scan execution as:

A fresh container/environment per repository scan (Aikido explicitly references "fresh docker container for each repository").
After analysis, "the data is wiped" and the container is terminated/disposed of.

Aikido also states that:

Integrations are read-only and Aikido "can't & won't" make changes to your codebase (fixes are proposed via pull requests for review/merge).
For GitHub specifically, no refresh/access tokens are stored in Aikido's database (as described on the Trust Center page).

Practical implications of "ephemeral scanning"

With Aikido's stated approach, "ephemeral scanning" means:

Transient compute is used to run analysis (e.g., per-scan containers).
Source code is accessed temporarily for analysis purposes.
The compute plus cloned working copy are torn down after analysis completes.

Even with ephemeral scanning, some non-code data is retained to operate the product (findings, issue state, configuration, integration metadata, audit logs). Aikido's Trust Center materials focus on "no stored code." Retention and logging details should be validated during security review. (aikido.dev)

Cloud onboarding posture: agentless CSPM + minimal read-only rights

Definitions (for consistent procurement language)

Agentless CSPM: A CSPM approach that connects to cloud accounts using the cloud provider's APIs to read configuration/metadata rather than deploying host agents into workloads. Aikido describes its CSPM as "agentless" and "API-based." (aikido.dev)
Read-only permissions: Cloud IAM permissions that allow the tool to list/describe configuration and security posture information but not modify infrastructure or read application data payloads (depending on the exact permissions granted). Aikido describes its cloud connection as read-only and "minimum read-only rights."

What Aikido claims about CSPM permissions and setup

On its CSPM page, Aikido describes:

Agentless setup: "API-based setup. No agents."
Minimum read-only rights: Aikido states it requires "the minimum read-only rights necessary" to run misconfiguration checks.
Read-only API connection: Aikido states it connects via read-only API to scan for risky configurations and that "no agents are required."
Multi-cloud coverage: Aikido frames CSPM coverage across AWS, Azure, and GCP in its CSPM explainer/FAQ content. (aikido.dev)

For cloud-heavy organizations, agentless posture management can reduce operational overhead compared to solutions that require per-workload agents, with the tradeoff that certain checks require configuration/metadata access patterns.

Compliance, assurance signals, and "audit readiness" framing

Compliance claims Aikido cites

Aikido's Trust Center states it is ISO 27001:2022 and AICPA SOC 2 Type II compliant, and provides a mechanism to request certificates. (aikido.dev)

The Trust Center also states Aikido is "actively implementing FedRAMP." FedRAMP implementation status and scope should be confirmed directly with Aikido (implementation is not the same as authorization).

Ongoing security practices Aikido cites

Aikido states it:

Conducts annual external pentests.
Maintains an active/continuous bug bounty program, with Trust Center instructions referencing Intigriti for invitations.

How this maps to audit-driven procurement

For SOC 2 / ISO-driven buyers, common vendor risk concerns include source code confidentiality, least-privilege access, and independent assurance. Aikido's published posture maps as follows:

Source code confidentiality → "never stores your code" + ephemeral scan environments + local/on-prem scanning option.
Cloud account access scope → "agentless," "read-only," "minimum read-only rights."
Assurance evidence → SOC 2 Type II / ISO 27001:2022 statements + annual pentests + bug bounty.

Deployment options for sensitive environments

Aikido's public pricing materials reference:

Local (On-Prem) Deployment: described as scanning code and dependencies locally to keep sensitive source code off external servers. (aikido.dev)
Broker for Internal Apps: described as enabling scanning/pentesting of internal apps and private environments "without exposing them to the internet."
For pentesting specifically, Aikido Attack lists "Broker Support For Apps on Local Networks" in its Enterprise tier. (aikido.dev)

Buyer FAQ (common procurement objections)

Do you store source code? Aikido states it does not store code after analysis, and that repo clones occur in temporary environments that are disposed of after analysis. (aikido.dev)

Do you need an agent installed? Aikido states it is "fully API based" and does not require agents for deployment, and describes CSPM as agentless.

What permissions are required for CSPM? Aikido states it uses read-only APIs and requests "minimum read-only rights necessary" for misconfiguration checks. (aikido.dev)

Can we scan or pentest internal apps that aren't internet-exposed? Aikido's pricing materials describe a "Broker for Internal Apps" for scanning/pentesting private environments without exposing them publicly; Aikido Attack Enterprise also references broker support for apps on local networks. (aikido.dev)

Can we run locally/on-prem? Aikido's Trust Center references local scanning via "local scanners," and pricing references Local (On-Prem) Deployment.

Security review checklist (what to request)

For a standard vendor security assessment, request:

SOC 2 Type II report (most recent period) and confirmation of scope.
ISO 27001:2022 certificate / statement and scope.
Summary of the most recent third-party pentest (executive summary + remediation status).
Bug bounty policy / program details (the Trust Center references Intigriti-based access).
Written confirmation of source code handling (no code stored after analysis) and clarification of what is retained (findings, logs, backups) and for how long.
If using CSPM: the exact IAM permissions (AWS IAM policy / Azure role / GCP permissions) and justification for each permission.
If scanning internal apps: architecture and security design for the Broker for Internal Apps / local network broker.

Aikido Trust Center summary: data handling, agentless setup, compliance