Trust is an architecture,
not a badge wall
Hiring an infrastructure firm means handing someone the ability to change — and destroy — the systems your business runs on. That's true whether our engineers are in your account or, later, your team is driving our platform. Here is exactly how that access is scoped, gated, and recorded, and an honest statement of where our compliance program stands.
The security model
The same rules govern engagement work and The Stoop platform. Where something is specific to the platform — currently in private pilot — it's marked.
Your account, your access, your revocation
We reach your cloud only through access you create, scope, and can revoke at any moment — a cross-account IAM role on AWS, federated credentials on Azure, named identities for the engineers on your engagement. Automated provisioning runs with short-lived, keyless credentials; no long-lived cloud keys for your account are stored in our pipeline.
No silent changes
Every change is planned before it's applied, scanned by a security review, priced before it's approved, and approved by a named human before it runs. Destructive operations are classified in the diff, and teardown requires explicit confirmation. Each tier's monthly cost ceiling is a hard stop in the pipeline — no approval by anyone, customer or operator, moves a build past it.
An audit trail by construction
Designs, plans, cost estimates, approvals, applies, drift events, and teardowns are all recorded on the environment's timeline. As-built documents export on demand. Your own CloudTrail independently sees every API call we make in your account.
Tenant isolation in the data layer
In the platform, customer data is separated with row-level security and owner-scoped access enforced in the database, not just the application. Access keys are scoped per capability and per customer, with per-account limits.
Your data never meets the AI
Identifying data is replaced with neutral tokens before any AI call; real values are injected into configurations by script, never by the model. Screening is server-enforced at every AI entry point with a hard credential-transmission backstop, models are commercially licensed (no training on your content), and the boundary is verified by a live test battery.
Centralized secrets, no hardcoding
Platform credentials live in a managed secrets vault as the single source of truth and are referenced by name — never committed to code. Rotation is a managed procedure, not an incident response.
Built for the bad day
We design to resilience levels with stated RTO/RPO — up to multi-region failover we've exercised live — rehearse recovery by cloning rather than hoping, and plan clean-room rebuilds that restore into isolation while a forensic hold protects the compromised original as evidence. The resilience practice does this work; the platform automates the parts that repeat.
We run on our own discipline
Row House Tech's platform infrastructure is itself managed as code, applied through gated pipelines, with least-privilege identities and no root usage. We sell the practices we operate.
Where we honestly stand
We're a young firm with a platform still in pilot, and we won't decorate this page with badges we haven't earned. Current status, plainly:
What we hold, and what we don't
What we store
- Engagement records: designs, plans, approvals, and the as-built history of what we built for you
- Infrastructure code and as-built metadata for your environments
- Account and billing information
What we don't
- Long-lived credentials to your AWS or Azure account
- Your application data — it lives in your account, behind your controls
- Your identifiers in AI prompts — the model only ever sees anonymized tokens
- Resale interest in your cloud spend — we take no percentage and no markup
Questions about a specific control, our subprocessors, or responsible disclosure? Email security@rowhousetech.com.
Put our answers in front of your security team
Request the whitepaper and questionnaire, or bring your review — we'll show up prepared.