Security model

Helix project code never contains, receives, or logs API credentials. Functions name a credential by alias; the Helix proxy resolves the alias, injects the secret server-side, forwards the request, and writes an audit log entry. This page walks through the mechanics for the engineer or IT reviewer asking why that is safe.

Credentials never enter project code

A project’s repository stores only a mapping from readable aliases to credential UUIDs:

// helix.config.ts
import { defineConfig } from '@trayai/helix-sdk';

export default defineConfig({
  workspaceId: 'f8e7d6c5-4b3a-2190-8765-abcdef012345',
  projectId: 'a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d',
  authentications: {
    salesforce_prod: '1a0fbf5c-2c9e-4aa1-ada3-ccbba65019ab',
  },
});

The UUID names a credential record on Helix’s servers, created and managed in the workspace (see connected services). Nothing in the repository, the environment, or the function runtime holds a token. When code makes an authenticated call:

// functions/api/v1/contacts.get.ts
import { defineFunction } from '@trayai/helix-sdk';

export default defineFunction(async (ctx) => {
  return ctx.http
    .authed('salesforce_prod')
    .get('{{instance_url}}/services/data/v59.0/query', {
      searchParams: { q: 'SELECT Id, Name FROM Contact' },
    })
    .json();
});

the SDK rewrites the request to the Helix proxy service. The function’s process never connects to Salesforce directly and never sees the token. Even the instance URL is a {{template}} variable the proxy resolves, so the code holds no environment-specific values at all.

What the proxy does with every call

1. Validates the caller. The proxy front door checks the function runtime’s service token before doing anything else.
2. Resolves the credential. It fetches the record by UUID, refreshes the OAuth token if it has expired, and substitutes {{template}} variables in the target URL.
3. Signs the request. The connector type stored on the credential record determines the signing strategy (see below).
4. Forwards. The signed request goes to the target API and the response streams back to your function.
5. Retries once on auth failure. If the target returns a 401 and the credential is OAuth-based, the proxy refreshes the token and retries once.
6. Logs. The full request and response are recorded with credentials redacted, tagged with project ID, execution ID, and auth alias, and visible in the dashboard at https://app.helix.tray.ai.

Signing strategies

Eight strategies cover how APIs authenticate. The connector chooses the strategy, never the developer, so code stays identical when a credential rotates or when two services authenticate differently:

What code can see

ctx.auth('alias') returns only fields the credential record classifies as non-sensitive, such as instance URLs and subdomains. Tokens, API keys, and secrets are never returned:

// functions/api/v1/sync.post.ts
import { defineFunction } from '@trayai/helix-sdk';

export default defineFunction(async (ctx) => {
  const vars = await ctx.auth('salesforce_prod');
  // { instance_url: 'https://mycompany.my.salesforce.com', subdomain: 'mycompany' }

  ctx.log.info('Syncing from org', { subdomain: vars.subdomain });
  return { started: true };
});

The same boundary holds in the dashboard: workspace readers can see which credentials a project uses, never their values.

Execution identity

Every deployed invocation carries an execution JWT minted by the platform and verified before it reaches your code. It holds exactly five claims: userId, projectId, workspaceId, organizationId, and executionId. Nothing else about the user is in the token; email deliberately never leaves the platform’s session store.

That token is also what observability trusts. Log and trace attributes identifying the tenant and execution are stamped server-side from the verified token at ingest, so nothing the function process claims about its own identity is taken at face value. The auth proxy applies the same rule, validating the runtime’s service token before resolving any credential.

IT control points

Visibility comes with enforcement. IT teams have four levers that apply across every project:

• Org-level middleware. Org admins can define middleware in the dashboard that runs on every request to every project, before any project code. It can block or modify requests (IP allowlists, security headers, logging to a SIEM), and every invocation of it is itself logged.
• Policies. Org-wide rules for credentials and integrations: approval requirements for new authentications, allow and deny lists for external services, credential rotation requirements.
• AI gateway controls. Budgets, model allow and deny lists, and rate limits for AI usage across the organization.
• Audit logs. Governance actions (credential changes, deployments, membership changes, middleware updates) are recorded with the acting user, timestamp, affected resource, and before and after state.

See governance for the full set.

Encryption

• At rest: AES-256 for databases, KV stores, and file storage.
• In transit: TLS 1.3 for all network traffic.
• Credentials: encrypted in the Helix auth service and never exposed to function code.

The same guarantees in local development

helix dev changes none of this. ctx.http.authed() calls go to the remote auth service even locally, so credentials are never downloaded to a developer’s machine. For offline work, helix dev --offline returns mock responses and makes no network calls at all.