Security at AOS.

1. Our approach

Security at AOS isn't a separate program — it's how the platform is designed. A separate database per customer. Encrypted credentials. A field-level audit trail by default. SSO with major identity providers. Soft-delete with deletion approval. The same controls that let your accountant defend a pay application three years later let your IT team defend the platform in a procurement review today.

The sections below describe how those controls are implemented. We're SOC 2-aligned in our controls; we're happy to walk a security team through specific evidence or fill out a questionnaire.

2. Infrastructure

AOS runs on managed cloud infrastructure in the United States. Major components:

The Service is delivered exclusively over TLS. HTTP requests are redirected to HTTPS at the load balancer; we do not accept unencrypted traffic.

3. Data protection

3.1 Encryption

• In transit: TLS 1.2+ between client and server, between AOS and our service providers (Twilio, AWS SES, Google, Microsoft), and between AOS and your authorized third-party integrations.
• At rest: database storage and object (file) storage are encrypted at the infrastructure layer by our cloud providers.
• Application-level encryption: per-customer integration credentials (API keys, OAuth tokens, webhook secrets) are encrypted at the application layer with industry-standard encryption (AES-128 + HMAC-SHA256) before they're saved. Decryption keys live only in protected runtime configuration, never in the database.
• Passwords are stored as industry-standard password hashing; we never store, log, or expose plaintext passwords.

3.2 Per-customer isolation

AOS keeps every customer separate from day one. Each customer has its own dedicated database. At sign-in, the central admin routes each request to the correct customer's database for the rest of that session. There is no cross-customer data access in the application; every query is bound to a single customer.

3.3 Customer data ownership

Customer data is owned by the customer. AOS does not sell customer data and does not use it to train AI models for the benefit of third parties. See our Privacy Policy for the full description of how data is collected, used, and shared.

4. Access control

5. External portals (board, alumni, sub-bid)

AOS exposes several public-facing portals that sign users in via a secure one-click link rather than a password: the board distribution portal (engagement-tracked board packets), the alumni pay-history portal (ex-employee W-2 / pay-stub access for the 7-year window), the sub bid portal, and the owner approval portal. These portals share a common security posture:

5.1 Blue Notary RON for lien waivers

Lien waiver notarization is performed through Blue Notary's remote online notarization service. The notarization job is opened by AOS at waiver-receive time; the waiver lifecycle refuses to advance from pending_notary to received until Blue Notary reports a completed signing session. Notary identity-verification credentials and session recordings are retained by Blue Notary in accordance with their RON certification; AOS retains only the signed PDF and the completion attestation.

6. Monitoring & logging

6.1 Field-level audit trail

Every business-critical write to the database — pay applications, change orders, RFIs, submittals, AP bills, timesheets, daily logs, schedule tasks — is recorded in a per-customer audit log with the user, timestamp, before/after values, and the originating request. The audit trail is tamper-resistant from the application; deletion of an audit row requires deletion-approval workflow with two-party sign-off.

6.2 Soft delete with deletion approval

Most records cannot be hard-deleted. They are flagged deleted, persist in the database for a configurable retention window, and require a deletion-approval workflow with a documented reason before any hard delete occurs. This protects against accidental loss and provides a defensible record for audits.

6.3 Application logging

Application logs are sent to secure log storage with retention appropriate to the service tier. Logs are scrubbed of obvious sensitive values (passwords, API keys, tokens) before persisting.

6.4 Login & impersonation events

Successful and failed sign-ins, password resets, Two-factor activity, and platform-admin impersonation events are recorded in dedicated event tables. Impersonation requires a fresh-password challenge plus a written reason and is auditable to the second.

7. Backups & recovery

Customer databases are backed up daily by our managed-database provider with point-in-time recovery available within the retention window. Object storage maintains durable, redundant copies of uploaded files within the storage region.

We test restoration on a recurring cadence and rebuild a non-production customer database from backup as part of operational drills. AOS will provide our most recent recovery test summary on request as part of a customer's procurement review.

8. Vulnerability management

• Dependency monitoring: we track third-party software dependencies for known security vulnerabilities and apply security patches on a priority schedule.
• Code review: every change to the system goes through peer code review before it ships. Security-sensitive changes (auth, encryption, access control, audit logging) are flagged for additional review.
• Automated code checks: code-quality and security checks run on every change.
• Penetration testing: AOS uses an independent third-party for recurring penetration tests as part of our SOC 2 alignment.
• Secret management: production secrets live in protected runtime configuration, are never committed to source control, and rotate on a schedule.

9. Incident response

AOS maintains a written incident-response plan covering detection, triage, containment, eradication, recovery, customer notification, and post-incident review. In the event of a confirmed security incident affecting customer data:

• We notify affected customers without undue delay, consistent with applicable law and our contractual commitments.
• Notifications include a description of the incident, the data affected, the steps we have taken, and what (if anything) the customer should do.
• Where required by law, we notify regulators within statutory timelines.
• A post-incident review is conducted and shared internally; customer-facing summaries are provided on request.

10. People & access

Access to production systems is limited to a small number of authorized engineers under formal access agreements. Access to customer data in production is on a need-to-know basis, time-bounded, logged, and reviewed.

All employees and contractors sign confidentiality agreements and complete onboarding security training. Background checks are performed where permitted by law for roles with elevated production access.

11. Compliance posture

12. Responsible disclosure

If you believe you have found a security vulnerability in the Service, please email us at security@aos.build with:

• A description of the issue and where you found it.
• Steps to reproduce.
• Any proof-of-concept materials, with sensitive data redacted.

We commit to:

• Acknowledge your report within 2 business days.
• Keep you updated as we triage and remediate.
• Not pursue legal action against good-faith research that follows the guidelines below.

Please do not access data that is not yours, modify or destroy data, run automated scans that degrade service, or publicly disclose findings before we have had a reasonable opportunity to remediate.

13. Contact

• Security reports: security@aos.build
• Procurement / questionnaires: security@aos.build
• Privacy: privacy@aos.build