How Cordanis is secured.
The security mechanisms of the Cordanis platform, stated plainly for security review. Everything on this page describes controls that exist today, not intentions.
01 System boundary
Every request follows one path:
- Browser → CloudFront. CloudFront is the sole public endpoint. All traffic is TLS.
- CloudFront → application API. Origins are private and reached through VPC origins. Load balancers are internal-only.
- API → agent runtime. The runtime is private. The browser cannot reach it; only the authenticated API can.
- Runtime → connected sources. Source access goes through a managed gateway restricted to configured providers. The browser never calls sources or the gateway.
- No public S3 buckets.
- No public load balancers.
- No Lambda function URLs.
- No unauthenticated endpoints. The only public routes are the bounded sign-in, signup-confirmation, and recovery entries.
02 Identity and sessions
- Authentication is Amazon Cognito. Every product endpoint validates a Cognito-issued JWT server-side on every request.
- Session tokens are delivered only in HTTP-only, Secure, SameSite cookies. No tokens in browser storage; page scripts cannot read them.
- Passwords and recovery codes are forwarded same-origin directly to Cognito. They are size-bounded, never logged, never persisted, and never returned in a response body.
- Auth responses are marked
no-store. Temporary challenge state expires in ten minutes.
03 Tenant isolation
- Organization and workspace membership is resolved server-side from membership records on every request. Browser-supplied organization or role values are never authority.
- Storage is private and scoped by organization and workspace prefix. Every read and write verifies ownership and allowed prefixes before the operation runs.
- The agent runtime is mounted only into the requesting workspace's scope. It has no path to another tenant's data. Mount isolation was last verified against the deployed stack in July 2026.
- Shared system skills are read-only to users and runtime sessions. Runtime write primitives reject shared paths.
04 What the agent can and cannot do
The Assistant's general toolbelt is read-only. External effects are not model capabilities; they are separate server operations gated on human confirmation.
| The agent can | The agent cannot |
|---|---|
| Read the workspace it is scoped to | Read any other tenant's data |
| Read connected sources through the managed gateway | Call provider APIs directly or hold provider tokens |
| Draft messages, research, plans, and prepared actions | Send email — the send operation is not exposed to the model at all |
| Write files inside its own workspace prefix | Mutate CRM records, enroll contacts, or delete data |
| Recommend a next move with cited sources | Execute any consequential action without a person |
Skill files are treated as executable influence over agent behavior and are controlled accordingly: shared skills are read-only and workspace skills are scoped to their owner.
05 Consequential actions
Sending, enrollment, CRM mutation, and destructive operations follow one flow:
- The system prepares the action and shows it to the seller.
- The seller explicitly confirms that specific action in the authenticated app.
- A deterministic server operation—not the model—executes it. The email send path, for example, is a single-operation gateway target reachable only from the seller-confirmed send command.
- The action is recorded with actor, target, and result.
06 Credentials and secrets
- OAuth for connected sources (Google, Salesforce, Slack) is owned by the managed gateway, which injects credentials at the transport layer. The agent runtime never holds your provider tokens.
- Application secrets live in AWS Secrets Manager or SSM Parameter Store—not in environment variables, client bundles, or code.
- The browser never receives storage credentials. Temporary file access uses short-lived signed URLs scoped to the requesting tenant.
- Source connections use least-privilege scopes and can be revoked at the provider at any time.
07 Audit and logging
- Every agent tool call and file write produces a run event: tool name, input summary, target resource, result status, error if any, and timestamp.
- Operational logs never contain message bodies, file contents, prompt bodies, tokens, auth headers, cookies, or signed URLs. Logs carry identifiers, status, and timing.
- An operator can trace a failed run end to end without reading customer content.
08 Data handling
- Customer data is stored in private, tenant-scoped AWS storage, encrypted in transit (TLS) and at rest (AWS-managed encryption).
- Model inference runs through Amazon Bedrock inside our AWS environment. Amazon Bedrock does not use your content to train models.
- Gmail reads flow through Google's hosted integration behind the gateway; Cordanis does not operate its own credential-handling wrapper around Google APIs.
- Connection diagnostics expose coarse readiness states only—never tokens, URLs, or source payloads.
09 Change control
- Infrastructure is defined as code (AWS CDK). Runtime configuration is never changed by hand.
- Deployments use immutable, build-specific image tags for auditability. Mutable tags are banned.
- Public-endpoint patterns, client-exposed secrets, and unauthenticated configurations are architecturally banned and checked in review.
10 Certifications
| SOC 2 | Not yet certified. No badge appears here before it is earned. |
| Independent penetration test | Not yet performed. Status will be published when it is. |
This page states only what is true today. For anything it does not answer, ask us the hard questions directly. We will bring engineers, not slides.
