Most AI infrastructure choices come down to a single question: where does my data go? BYOC (Bring Your Own Cloud) is the answer for teams that can't or won't send raw data to a vendor's servers. But BYOC as a concept is cleaner than BYOC as a deployment — and there are real differences between architectures that claim it.

This post walks through how Foundri's BYOC deployment actually works — step by step, from the moment you decide to deploy through to continuous operation. If you're evaluating BYOC vendors or just curious about what's happening in your account, this is what the deployment looks like.

The 4-Step BYOC Deployment Model

Step 01 / 04
Agent package is built as a container image
When you request a deployment, Foundri builds your agent as a standard Docker container image. No proprietary runtime, no Foundri-specific framework — just a Dockerfile that packages the agent code, its dependencies, and a startup script. The image lives in your AWS ECR (Elastic Container Registry) under your account.
# Standard Dockerfile — no magic
FROM node:20-alpine
COPY agent /app
RUN npm install --production
CMD ["node", "agent.js"]
Why this matters: You own the image. You can pull it, inspect it, scan for vulnerabilities with your own security tools, and redeploy it anytime. There's no dependency on Foundri's registry or Foundri's build pipeline.
Step 02 / 04
Container deploys into YOUR VPC via CloudFormation
Foundri provides a CloudFormation template (or Terraform equivalent). You review it, run it in your account, and it provisions the infrastructure: a VPC subnet, security groups, an IAM role, and an ECS task. The agent runs on EC2 or Fargate — your choice. The entire deployment is in your account, under your control, and visible in your AWS console.
# Your CloudFormation template
Resources:
AgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePrincipalService: ecs-tasks.amazonaws.com
Policies:
- PolicyName: AgentAccess
PolicyDocument:
Statement:
- Effect: Allow
Action: [s3:*, rds:*, ec2:*]
Resource: [arn:aws:s3:::YOUR-BUCKET/*]
Why this matters: The IAM role defines exactly what the agent can access. If you want the agent to read S3 and query RDS, those are the only permissions it gets. You control the boundary. The agent running in your account cannot reach anything outside that policy — not Foundri's infrastructure, not other AWS accounts, nothing.

Key security boundary: The agent can access YOUR infrastructure (databases, S3, APIs running inside your account). It cannot initiate outbound calls to arbitrary endpoints. It cannot bypass the IAM role. It cannot reach Foundri's infrastructure to request data or instructions beyond the initial deployment config.

Step 03 / 04
Agent connects to YOUR databases and APIs — never routes data through Foundri
Once running, the agent processes work in your environment. It reads from your RDS databases, queries your APIs, modifies your S3 buckets, updates your DynamoDB tables — whatever you've configured it to do. The data never leaves your AWS account during processing. The agent runs, transforms data, writes results, and stays internal.
Data flow during a typical workflow:
  • Input: Agent queries your RDS database for compliance evidence
  • Processing: Agent runs analysis on the data (still in your account)
  • Output: Agent writes results to your S3 bucket or RDS database
At no point does the raw data or intermediate results travel to Foundri's servers. The agent is compute running inside your boundary. Your infrastructure is the execution environment.
Step 04 / 04
Foundri receives only telemetry — no payload data crosses the boundary
The agent does emit data back to Foundri, but only operational telemetry: task completion status, latency, error codes, and event counts. Think CloudWatch metrics, not raw data. Examples of what Foundri sees:
  • Agent started at 2026-04-22T14:30:00Z
  • Task completed in 2.3 seconds
  • Query 1: 0.8s | Query 2: 1.2s | Processing: 0.3s
  • Status: success | Records processed: 1,247
  • Error code: none
What Foundri does NOT see: the actual database records, the content of your S3 objects, email addresses, transaction amounts, or any payload data. The telemetry stream is firewalled at the field level.

Security Boundaries — What Foundri Can and Cannot See

Category What Foundri Sees What Stays in Your Account
Raw Data — Database records, files, emails, logs
Processed Data — Transformed results, intermediate outputs
Execution Metrics Latency, status, error codes, task duration —
Operational Logs CloudWatch logs (aggregated, not raw) Detailed logs remain in your account
Infrastructure Config IAM policy (you provide it) AWS credentials, API keys, connection strings
Deployment State Running / Stopped / Errored Task logs, debug info

The boundary is enforced at the agent code level. Every outbound message to Foundri is a signed telemetry packet that excludes payload fields. The agent has no code path to extract or transmit raw data — those instructions don't exist.

How This Differs From "Hosted" Competitors

Most compliance and automation tools offer a similar story: "Your data is safe on our servers. We're SOC 2 certified. We use encryption." And that may be true. But the architecture is fundamentally different.

Hosted vendors (Vanta, Drata, etc.): Your data flows to their infrastructure for processing. They apply controls — encryption, access logging, incident response — but the data leaves your account. For many enterprises, that's an architectural violation. HIPAA-covered entities cannot send patient data to third-party servers without explicit Business Associate agreements and audit controls. Finance teams cannot pipe transaction data to vendors that process it offshore. Government contractors often cannot move data through cloud providers at all.

BYOC (Foundri): Your data never leaves your account. Processing runs in your cloud. The vendor never receives or stores raw data — only operational metrics. There's no data residency question, no compliance exception, no "we promise we won't train on your data" fine print. The architecture enforces the boundary.

Practical difference: With a hosted vendor, you're asking "Can I trust this company?" With BYOC, the question becomes "Do I trust my own AWS infrastructure?" — which is a question you've already answered as a customer.

What Happens When the Agent Runs

Here's a concrete example: SOC 2 evidence collection.

  1. You schedule the agent to run daily at 2 AM.
  2. ECS wakes the container. The agent connects to your RDS database and your API layer (no Foundri involvement).
  3. Agent queries: "How many security patches were deployed in the last 24 hours? What are our active API tokens? Which users changed access levels?"
  4. Agent processes the raw data locally, generates a compliance report, writes it to your S3 bucket.
  5. Agent emits telemetry: "Task completed. 23 security events processed. 847 tokens audited. Runtime: 1.2 seconds. Status: success."
  6. Foundri receives the telemetry and stores it in the Foundri dashboard under your account (metrics only — no report content).
  7. You download the report from your S3 bucket. That data was never transmitted to Foundri.

Your security team can audit the entire flow. The agent ran in your VPC under an IAM role you defined. The outputs are in your S3 bucket. The only data Foundri touched is a six-line telemetry blob with no payload content.

Monitoring and Debugging

Because the agent runs in your account, debugging follows AWS standards.

If something goes wrong, your infrastructure team investigates in your AWS console. There's no "Please contact support and we'll check our servers" — the evidence is already in your account.

Is This the Same as Every BYOC Deployment?

No. The word BYOC is used to describe a spectrum of architectures, and not all are equal.

Real BYOC: Agent runs entirely in your cloud. No data reaches the vendor. Telemetry only. This is what Foundri does.

Marketing BYOC: Agent installs in your VPC but maintains a persistent connection back to the vendor's control plane. The agent "calls home" for instructions, config updates, or data submission. Raw data may not leave your network, but the agent's actions are orchestrated from the vendor's servers. You don't control when the agent runs or what it processes — the vendor does. This is common among competitors.

Hybrid BYOC: Agent runs in your cloud, but some processing happens on the vendor's servers. Certain "analysis features" are not available without sending data to the vendor. You choose per-workflow whether to use the full feature set (requires data transmission) or the restricted set (stays local). This is offered by some vendors as "flexibility."

When evaluating BYOC, ask directly: Does any of my data leave my cloud account during normal operation? What exactly does your agent send back to your servers? Can your servers trigger actions in my account, or only in mine?

Getting Started With Foundri's BYOC

The deployment itself is straightforward.

  1. You describe the workflow you want to automate (usually compliance, data processing, or log analysis).
  2. Foundri builds an agent and a CloudFormation template tailored to your infrastructure.
  3. You review the template in your AWS console, approve it, and deploy.
  4. The agent starts, completes its first task, and reports success.
  5. You get a report in your S3 bucket. Foundri receives metrics in the dashboard. Done.

No credentials to share. No data uploads. No compromise on your infrastructure. That's BYOC done right.