​

0.1 — Architectural principles — the invariants that govern every agent deployment.

The Layerup AI Agents architecture is built on a set of non-negotiable invariants. These are not aspirational design goals or configurable settings. They are structural properties enforced by the deployment model, the container design, and the IAM boundary — present in every production deployment regardless of the customer’s specific configuration choices. Enterprise architecture and information security teams should treat these as baseline guarantees before evaluating any individual capability.

---

​

0.1.1 Sovereign tenancy — by construction, not by policy

Your organisation does not share compute, memory, network space, or data storage with any other Layerup customer. The agent is provisioned exclusively within your own cloud account and executes within your own Virtual Private Cloud (AWS) or Virtual Network (Azure). This is categorically different from the traditional AI-as-a-Service model, where an enterprise sends application data to a multi-tenant API endpoint hosted outside its network. Sovereign tenancy in the Layerup model is architectural — it follows from the fact that the agent runs as a container inside your account, not from a policy that Layerup applies to a shared infrastructure layer. Enforcement mechanism: Container runs inside your VPC private subnets. Your network controls the traffic. Your IAM controls the identity. Layerup cannot access your compute environment.

---

​

0.1.2 Zero-egress data residency — no application data leaves your boundary

At no point in the production operation lifecycle does any of the following leave your network boundary:

• Raw application documents (PDFs, medical records, financial statements)
• OCR-extracted text or normalized data fields
• LLM prompts constructed by the agent
• Model inference responses
• Agent reasoning chains and working memory
• Confidence scores, underwriting recommendations, or flagged inconsistencies
• Audit logs and step-level telemetry

LLM inference is routed exclusively to Amazon Bedrock (AWS) or Azure OpenAI (Azure) via private VPC Endpoints or Private Link — managed services that operate within your cloud tenant under your data processing agreements, and that have committed not to use your data for model training. Enforcement mechanism: Private subnets with no Internet Gateway route. VPC Endpoints for all AWS service communication. Security Groups permitting no inbound traffic from outside the VPC and only explicitly whitelisted outbound destinations.

---

​

0.1.3 No-new-perimeter posture — your controls govern the agent

The Layerup agent does not introduce a net-new security perimeter that your information security team must learn, monitor, and audit separately. Every security control applied to the agent workload is a native control your team already owns and operates: Enforcement mechanism: The container is framework-agnostic and uses standard AWS SDK / Azure SDK calls. It does not introduce proprietary network tunnels, agent management endpoints, or telemetry sidecars that phone home to Layerup.

---

​

0.1.4 Least-privilege identity — scoped, enumerated, deny-all by default

The agent container is granted only the specific, enumerated IAM permissions required to perform its defined workflow functions. A deny-all default policy explicitly blocks everything else. The agent cannot: access S3 buckets outside its designated input/output paths; invoke Bedrock models outside the specifically approved model ARNs; read Secrets Manager secrets outside its designated path; call EC2, RDS, or any other service not listed in its execution role policy. No Layerup personnel hold any IAM credentials in your cloud account during production operation. Any access during the implementation engagement is performed via a time-limited, audited role that is explicitly revoked upon production go-live. Enforcement mechanism: IAM Execution Role with explicit deny-all and explicit allows for only the required operations. Azure equivalent: User-Assigned Managed Identity with RBAC scoped to specific resources.

---

​

0.1.5 Configuration as code — the AOP is the agent’s operating contract

The agent’s reasoning behaviour is governed entirely by its Agent Operating Procedure (AOP) — a version-controlled, human-readable configuration artifact that encodes your underwriting rules, risk thresholds, occupation classifications, financial benchmarks, and escalation criteria. The AOP is not embedded in the container image. It is stored in your source control system (AWS CodeCommit, GitHub Enterprise, or equivalent), subject to your change management and approval workflows. Every change to the AOP is attributed to a specific author, associated with a pull request, and reviewable by your underwriting governance team without requiring software engineering expertise. Enforcement mechanism: AOP is loaded at runtime from your version control system. The container image version and the AOP version are independently tracked and logged against every processed case.

---

​

0.1.6 Governed inference — guardrails are your controls, applied at inference time

The agent invokes foundation models through Amazon Bedrock or Azure OpenAI — both services that your team procures, configures, and governs within your cloud tenant. Bedrock Guardrails and Azure AI Content Safety policies are configured by your platform team and applied as a middleware layer to every inference call the agent makes. The agent has no code path that bypasses the guardrail layer. Guardrail interventions — PII redaction, topic denial, prompt injection blocks — are logged in full detail to your audit infrastructure. The agent does not retry past a guardrail block; instead, it escalates the case for human review. Enforcement mechanism: All inference calls are routed through the guardrail-enforced Bedrock / Azure OpenAI endpoints. The agent’s IAM role is scoped to bedrock:ApplyGuardrail as a required permission for all inference invocations.

---

​

0.1.7 Fail-and-escalate — deterministic fallback, never silent failure

The agent is designed to never silently fail. Every error condition — OCR failure, model timeout, low-confidence extraction, guardrail intervention, out-of-scope edge case — results in a deterministic, logged fallback action. The escalation path is always to a human underwriter, never to a hallucinated output. Specifically:

• Any case where overall confidence falls below the configured threshold (default: 75%) automatically receives an Escalate to Senior Underwriter recommendation, regardless of other findings.
• Any case where a critical data point cannot be extracted from available documents results in automatic escalation.
• Any case where the agent encounters a pattern outside its AOP coverage is flagged explicitly as requiring human judgment — the agent does not extrapolate beyond its configured scope.

Enforcement mechanism: Confidence threshold checks are hard-coded in the agent’s output assembly layer, not configurable via prompting. The escalation flag is written before the output payload is assembled; it cannot be suppressed by downstream logic.