Security

What we run

Armorer sells continuous security verification for AI agents. A customer installs the read-only Armorer GitHub App. The hosted platform clones a repository at a pinned commit into an ephemeral task and runs discovery, attack simulation against an isolated copy of the agent, and remediation synthesis, then returns evidence and a draft pull request that Armorer never merges. Armorer Guard is a runtime enforcement binary that customers install on their own hosts; we build, sign and publish it and receive content-free decision telemetry, licensing and coverage data from it.

The system described on this page is the hosted service (the Console at console.armorerlabs.com, the API at api.armorerlabs.com, the platform control plane, hosted scanning and Guard telemetry ingestion) together with the Guard binary and the pipeline that builds and publishes it. This website runs in a separate account outside that boundary.

We are a two-person company. Daniel Begimher, co-founder and CEO, is the Information Security Officer; Cristian Leo, co-founder and CTO, is the deputy. Every control on this page is operated by one of the two of us, and where that is a limitation we say so below.

Hosting and data location

Amazon Web Services is the primary cloud for the hosted service and the only cloud intended to hold customer metadata. The home region is us-east-1; us-west-2 is permitted and is used only for a second threat-detection deployment. Azure and Google Cloud are used for development and testing and are not intended to receive customer source code. We run seven accounts under one AWS Organization: management, security tooling, log archive, production, staging, sandbox and website. Production is separated from staging and sandbox, and the documented production infrastructure is defined in code with the AWS CDK.

Access control

• Access to AWS is federated. Google Workspace is the identity provider, connected to AWS IAM Identity Center by SAML with automated user provisioning and group-based assignment. Access is granted through groups, never to an individual directly.
• There are zero IAM users and zero long-lived access keys across the seven accounts, and no member account has root credentials.
• Deployment automation assumes short-lived roles through OpenID Connect from GitHub Actions rather than holding credentials.
• Two-step verification is enforced in Google Workspace, and two-factor authentication is required across our GitHub organization.
• When someone leaves, access removal starts with suspending their Workspace identity, which removes their federated access to AWS.

Several software-as-a-service tools we use sit outside single sign-on; see the limitations below.

Encryption

In transit

Both customer-facing hosts require TLS 1.2 or higher and send Strict-Transport-Security with a two-year max-age, includeSubDomains and preload, together with nosniff, no-referrer and frame-denial headers.

At rest

Every production data store is encrypted. As of the live check on 2026-09-09, 21 of 24 production DynamoDB tables use customer-managed KMS keys and three use the AWS-managed DynamoDB key. Buckets holding customer-derived artifacts use customer-managed keys; log and telemetry buckets use SSE-S3. Every bucket blocks public access on all four settings. Per-tenant encryption is partial: five tenant-specific key aliases exist and three tables reference them, and tenant keys are provisioned as tenants are onboarded rather than in advance.

Recoverability

Point-in-time recovery is enabled on all 24 production tables captured on 2026-09-09, deletion protection is enabled on 23, and object versioning is on for durable buckets. A restore of an empty staging table proved the recovery mechanism and timing; a production-table restore with content validation is still pending.

How customer source code is handled

• Repositories are read through the read-only Armorer GitHub App with tokens that are short-lived and scoped to a single repository. Tokens are never written to a log or a file and are not reused across tenants.
• A scan clones the repository at a pinned commit into an ephemeral task in the production account. The working copy is destroyed with the task and is not written to a durable bucket or table, except in the two cases stated in our Privacy Policy: retention a customer approves for an open support case, and a copy kept only as long as it takes to reproduce a reported defect and then deleted.
• Source code is never copied to a laptop, a shared document, a work item, a CRM record or a chat message, and is never pasted into the coding assistants or the code review tool we use on our own source.
• Apart from the model-provider call described below, the only outbound flows of code-derived content are the evidence bundle, whose schema excludes source code, and the draft pull request returned to the customer repository, which Armorer never merges.
• Agent traces and checkpoints are off by default, enabled only at a customer's request, and kept for 30 days.
• During an opt-in hosted scan, the customer source being scanned and the findings derived from it are sent to the model provider named in the subprocessor listbelow, under that provider's API terms. The provider's published business terms restrict training use absent explicit agreement. Account-specific retention settings and any zero-data-retention approval have not yet been independently confirmed.

These placement rules are enforced by how the platform is built and by founder discipline. We do not run data loss prevention or egress filtering tooling.

Change management

• All infrastructure is AWS CDK in TypeScript across three application repositories, so every production change is reviewable and reconstructable from source.
• Every change to a production repository reaches the default branch through a pull request under organization rules that also block force pushes and branch deletion. Bypass access is limited and its use is treated as a break-glass event.
• Company policy requires continuous integration and an automated AI code review on human-authored pull requests. The exact required status checks vary by repository and are not represented as one universal GitHub gate.
• CodeQL code scanning, secret scanning with push protection, and Dependabot security updates are enabled on every production repository, private ones included.
• Platform and Console deployments run in GitHub Actions with roles assumed through OpenID Connect. The infrastructure repository deploys from a founder's federated session through a script that requires a clean checked-out branch, a typed risk-tier confirmation and an append-only deploy log.

What we do not have: no pull request requires approval by a second person. With two engineers, we chose a required pull request, automated review and repository-specific checks as the merge gate, and we disclose the resulting segregation-of-duties limitation rather than describe a control we do not run.

Logging and monitoring

• One organization-wide, multi-region AWS CloudTrail with log-file validation, encrypted with a customer-managed key, is delivered to a dedicated log-archive account. The archive bucket carries S3 Object Lock in compliance mode for 90 days, so no one, including us, can alter or delete a record inside that window. A second trail records object-level events on the artifact bucket.
• Audit log retention is 90 days and no longer. Extending it to 12 months is on our roadmap and is not in place today.
• Amazon GuardDuty is enabled organization-wide in both permitted regions. Today only high-severity findings in us-east-1 reach founder email; findings in us-west-2 do not yet reach a notification channel, and email is our only alert channel.
• AWS Security Hub and AWS Config are deferred. With two founders and infrastructure defined entirely in code, drift is caught at synthesis and review. Both tools are scheduled for whichever comes first of a third person gaining production access or a customer contract requiring continuous configuration monitoring.

Vulnerability and incident management

• Our target is to remediate critical vulnerabilities within 7 days of becoming aware of them and high vulnerabilities within 30 days, or to record a dated exception.
• Code scanning, dependency alerts and secret scanning were enabled on every production repository on 2026-09-03. The first-run backlog they produced is being triaged and is not yet clear.
• Every security incident a founder becomes aware of is recorded in the incident log and reviewed under our Incident Response Plan, which defines two roles, a severity table and evidence preservation against the 90-day audit trail. We notify you without undue delay and within 72 hours of confirming an incident affecting your data.
• No independent penetration test has been performed yet. The first is committed within 12 months of our security policy's approval.

Known limitations

These are the gaps we know about. They are stated here so that they are disclosed rather than discovered.

• Two founders operate every control. Segregation of duties on code changes is a disclosed limitation, and no pull request requires a second person to approve it.
• No device management tool is deployed on the two founder laptops. Full-disk encryption is on for both and is attested by each founder rather than enforced by tooling.
• No managed network firewall and no egress domain allowlist are deployed; egress is controlled by security-group rules. A web application firewall protects the Console but not the API host.
• Audit log retention is 90 days.
• Email is the only alert channel, and GuardDuty findings in us-west-2 do not reach a channel yet.
• Several software-as-a-service tools sit outside single sign-on.
• Cloud security posture management and continuous configuration recording are deferred.
• An empty staging-table restore proved the recovery mechanism but not production data fidelity. A production restore with content validation, an independent penetration test, an access review and a tabletop exercise are still pending. The recovery objectives for a primary-region failure are 24 hours to restore service and 1 hour of data loss, and they remain unproven.
• The customer deletion procedure is documented but has not been exercised, because no customer has departed yet.
• Per-tenant encryption keys cover part of the production data, as described under Encryption.

Compliance

A SOC 2 Type 1 examination covering the Security trust services category is in preparation. Armorer does not currently hold a SOC 2 report, and nothing on this page is a certification of the service. We publish this page so that customers can evaluate our controls directly in the meantime, and we will update it when the examination completes.

Subprocessors, as listed on 2026-09-10

The providers below can reach customer data or sit in the production data path. The list was last checked against the current vendor register on 2026-09-10. Provider roles that remain unconfirmed are not presented as customer-facing production use. We check the list by hand whenever a provider is added or changed and at an annual review.

Marketing and website providers, outside the hosted service boundary

Where a customer agreement requires notice of subprocessor changes, we update this list in the same change that adds the provider and email the customer's account contact at least 30 days before the new provider begins processing customer data.

Reporting a vulnerability

If you believe you have found a vulnerability in the hosted service, the Guard binary, this website or an Armorer repository, email security@armorerlabs.com. Include what you found and where (the host, repository or Guard version), the steps to reproduce it, and any proof of concept.

• Do not access, modify or delete data that is not yours, and do not test against customer repositories, Console tenants or Guard installations you do not own.
• Do not run denial-of-service, spam or social-engineering tests.
• Give us reasonable time to remediate before disclosing publicly.

We acknowledge reports within 5 business days. Researchers who act in good faith and follow this policy will not face legal action from Armorer for their research. We do not offer a monetary reward at this time.

The machine-readable contact for security researchers is published at /.well-known/security.txt (RFC 9116).

About this page

Statements on this page are drawn from our internal system description and security policies, current as of 2026-09-10, and are updated when a control changes. Questions go to security@armorerlabs.com.