Security by design: how Tealfabric keeps automation and AI in bounds

When you connect business systems, run custom automation, and let AI agents act on live data, security stops being a checkbox on a landing page. It becomes a design question: what runs inside your scope, what code and agents are allowed to do, which integrations may be called, and what happens when a document or webhook tries to smuggle instructions into a model.

Tealfabric is built around one workspace boundary — a tenant — where processes, integrations, published WebApps, documents, and agents share the same isolation, policy scope, and audit trail. This post explains the controls you can rely on today, what each one is meant to prevent, and where responsibility still sits with your team.

For step-by-step configuration, follow the Security, privacy, and compliance section of the Library. This article is the narrative version.

The problem we are solving

Most production incidents in automation and AI fall into a small set of patterns:

• Runaway code — a script or step calls the network, filesystem, or shell in ways nobody reviewed.
• Credential sprawl — API keys and passwords live in source code, chat logs, or shared documents.
• Over-trusted models — retrieved web pages, uploaded files, or webhook payloads are treated as instructions instead of data.
• Silent side effects — an agent or process changes records, publishes a new entry point, or executes an integration without an accountable human decision.
• Weak boundaries — automation, API keys, or agents reach data or actions outside the tenant scope or their configured allowlists.

Tealfabric addresses these with layered defaults: fail closed where possible, explicit opt-in for risky execution, and separation between what the model reads and what the platform allows to run.

One tenant, one policy plane

A tenant is the strict scope boundary for everything security-relevant: stored data, file storage, integration credentials, process definitions, agent configuration, execution logs, and guardrail overrides. API and console traffic are evaluated inside that boundary — not as a shared pool where automation from one customer could reach another’s records.

That scope is deliberate for governance work. When auditors ask “what is in scope for this system?” or “where do controls apply?”, a tenant gives a clean answer: one organization’s automation, data, and AI activity live in one container, with one set of policies and one place to collect evidence. Teams preparing for SOC 2, NIS2, or ISO 27001 reviews often benefit from that clarity — scope, ownership, and control boundaries are easier to describe than when processes, agents, and integrations sprawl across unrelated tools without a common perimeter.

Within the tenant, policy is not only “who signed in.” It is also what the platform allows to run:

• Orchestration guardrails — category allowlists, forbidden operations, rate and resource limits, tenant-specific restrictions, and audit settings for AI-driven work (MCP guardrails).
• Process and integration fences — sandbox capability profiles, keystore-backed secrets, and per-integration opt-in for agent execution.
• Agent allowlists — explicit lists of processes and peers an Autonomic Agent may dispatch, plus bounded file and token usage.

Monitor gives operators execution history and queue visibility so failed runs and unusual activity are inspectable instead of invisible background jobs — the operational side of the same scoped boundary.

Workspace roles and sign-in methods still matter for day-to-day administration; they are covered in the user roles and tenant SSO guides. This post focuses on the tenant as a control container: isolation first, then policies and guardrails that apply uniformly to automation and AI inside it.

ProcessFlow sandbox: automation code with a guardrail

ProcessFlow runs step code in a sandbox on shared infrastructure. The sandbox is not a suggestion — blocked patterns fail at save time or at run time, rather than executing partially.

What the sandbox blocks

By default, step code cannot use arbitrary shell commands, dynamic code evaluation, raw database drivers, unrestricted module loading, or direct outbound HTTP to any host. Environment mutation and low-level server globals are also out of scope.

That design targets a specific risk: tenant isolation bypass and platform instability from unconstrained code on multi-tenant infrastructure.

What you use instead

Steps call approved platform services — tenant database access, integration connectors, approved AI Agents, internal APIs, files, notifications, and LLM helpers — through a controlled surface documented in the Process sandbox API reference. If a step needs a connector, it goes through the connector path; if it needs HTTP to your own APIs, it uses the secured API helper; secrets come from the encrypted keystore, not hard-coded strings in the snippet.

Capability profiles

Each run carries sandbox capabilities — for example logging, data access, connector use, API calls, files, keystore, or LLM. Calling a service without its capability enabled fails at runtime. That lets you ship a read-only diagnostic step beside a full integration bridge step without giving every snippet the same power.

Treat a guardrail error as design feedback: move the behavior to an approved service, validate inputs earlier, and keep each step focused on one safe action. See Sandbox guardrails for the full checklist.

Integrations: governed paths to external systems

Tealfabric ships a large connector catalog that can be used in secured integration connections. Integrations are configured objects with credentials stored for the tenant, test and history in the console, and execution paths that ProcessFlow steps and Agents use instead of ad hoc HTTP.

For AI specifically, each integration can be marked whether it is executable by AI agents. Leave that off until you explicitly want Trace AI or an Autonomic Agent to call that integration. Read-only lookups and write operations can be separated so agents do not inherit every connector your operators use.

OAuth2 and credential handling follow the patterns in Connecting systems. Pair connector setup with least-privilege scopes on the external system wherever the vendor allows it.

AI agents: policy before prompts

Trace AI, the Platform Engineer Agent, and Autonomic Agents operate through the same tenant boundary as the console, but they are not unconstrained chat windows. Orchestration is governed by MCP guardrails — structured limits on categories, forbidden operations, role requirements, tenant restrictions, rate and resource limits, and audit settings.

Guardrails answer: which classes of work may run, how often, and under which roles. They are independent of whatever the model says in natural language.

Tenant skills without expanding power

Tenant skills package instructions under your workspace SKILLS/ folder. Trace AI loads them on demand. A skill can describe how to work; it does not grant tools beyond what the platform already allowed for that session. Declared capabilities in a skill package are intent, not permission. The platform intersects them with the active tool set.

That reduces the risk of a pasted playbook silently unlocking integrations or mutations the administrator never enabled.

Untrusted data and prompt injection

AI systems routinely ingest text they did not author: user messages, documents, web pages, webhook payloads, and process input. Tealfabric treats much of that content as untrusted data, not as system policy.

Concrete behaviors you can expect:

• External and machine-supplied input uses a stricter filtering profile than interactive chat from a signed-in user.
• Oversize messages are rejected rather than silently truncated.
• High-signal injection patterns in untrusted text may be quarantined before they reach the model.
• After the agent retrieves external content in a turn, high-impact platform mutations in the same turn are restricted — so a poisoned web page cannot immediately chain into “run this process” or similar actions. Server-side allowlists still apply; filtering reduces impact but does not replace them.
• Web fetch for agents is constrained to safe HTTPS usage, with blocks on private and internal network targets, including through redirects.

These controls reduce prompt-injection impact. They do not make agents immune to manipulation. Design workflows assuming the model can be misled — and rely on allowlists, confirmations, and sandboxed processes for anything that matters.

See Trace AI Agent and the prompt-trust section of MCP guardrails for operator detail.

Human confirmation before side effects

Interactive agents support human-in-the-loop confirmation: destructive file moves, deletes, process execution, WebApp publish, and other sensitive actions can require an explicit Accept or Deny in the UI before the tool runs. Permission questions belong in that confirmation channel — not as a casual “Shall I proceed?” in chat text.

Autonomic Agents are unattended workers woken by schedule, webhook, or process event. They do not use interactive confirmation path. They are designed for bounded, allowlisted automation instead. When a decision requires a person, the agent returns a need human outcome and records why.

Autonomic Agents: unattended work with explicit fences

Autonomic Agents run outside the chat console. Each definition includes a mandate (standing playbook), optional tenant skill, triggers, and hard lists of what it may touch.

Important defaults:

• Allowed process IDs — empty means the agent cannot start or wake processes via dispatch. Wildcard “any process” is not the default for new definitions.
• Allowed peer agent IDs — controls which other Autonomic Agents it may message.
• Execution context — each wake runs under a fixed tenant user context: the process execution identity from the trigger, or an optional dedicated service user on the agent definition (see Autonomic Agents — security). The platform rejects unsafe pairings such as tenant administrator plus a wildcard process allowlist.
• Concurrency limits — prevent one stuck run from blocking all future wakes.
• Working directory — file tools for Autonomic Agents are scoped to that agent’s workspace folder under tenant storage.
• Token budgets — weekly and monthly caps on unattended model usage.

Enable Autonomic Agents only when your deployment operator has turned the feature on for your environment. Start in draft, test with manual runs, then activate triggers when the mandate and allowlists match what you are willing to automate while you sleep.

Programmatic access: API keys with scope and hygiene

Server integrations use API keys with HTTPS, tenant headers, and scopes such as chat access where applicable. Keys are shown in full only at creation.

Machine callers that invoke chat or process-backed agent paths are treated as external ingress for filtering — appropriate when the body is supplied by another system, not typed by a logged-in operator.

Describe before write

Agents that create or change platform resources are expected to follow a describe → assemble → confirm → act rhythm: inspect shape and IDs with read tools, build a minimal payload, confirm when the action is destructive, then mutate. That pattern is documented in Agent payload contracts and Platform actions.

It does not eliminate mistakes, but it cuts down impulsive writes from guessed field names or stale IDs.

How the layers fit together

Think of Tealfabric security as three cooperating planes:

┌─────────────────────────────────────────────────────────────┐
│  Tenant boundary — isolation, scoped storage, audit, Monitor  │
├─────────────────────────────────────────────────────────────┤
│  Policy plane — guardrails, allowlists, integration opt-in, │
│                 API key scopes, compliance-oriented settings  │
├─────────────────────────────────────────────────────────────┤
│  Execution plane — sandbox capabilities, keystore, agents,  │
│                    connectors, confirmations                │
└─────────────────────────────────────────────────────────────┘

Ingest — connectors, documents, webhooks, agent web fetch — enters through configured or filtered paths. Decide — the model plans inside tool and guardrail limits. Act — side effects run as sandboxed process steps, allowlisted integrations, or human-approved mutations.

Agents do not replace the ProcessFlow sandbox; they orchestrate work through it and through the same integration objects your operators configure.

What Tealfabric does not claim

Honest expectations keep deployments safe:

• Prompt injection is not solved. Filtering and sequencing reduce risk; they do not guarantee the model will always refuse a clever attack. Keep destructive work behind confirmations and allowlists.
• Guardrails are not a substitute for external least privilege. Lock down CRM, ERP, and cloud accounts on the vendor side too.
• Compliance certifications — Tealfabric does not certify your SOC 2, NIS2, or ISO 27001 posture for you. A scoped tenant, documented guardrails, and Monitor evidence can make your audit preparation easier; use the security checklist with your assessor’s control mapping.
• Every UI action is not yet mirrored in agents. Agents are strong on read, search, governed execute, and assist paths; expand coverage deliberately with your administrator.

Security here means defaults that fail closed, explicit opt-in for agent execution, and one tenant boundary for automation, data, surfaces, and AI — not a slogan that nothing can go wrong.

Practical starting points for your team

1. Treat the tenant as the audit unit — document what runs inside it (processes, agents, integrations, data stores) before expanding scope.
2. Configure MCP guardrails for your categories, forbidden operations, and tenant restrictions before broad agent rollout.
3. Review sandbox capabilities before publishing processes that touch connectors or files.
4. Store secrets in the keystore — rotate on the same schedule as external API credentials.
5. Leave agent execution off integrations until you have named owners and test cases for each call path.
6. Use confirmation for deletes, moves, publish, and production process execution from chat.
7. Run Autonomic Agents in draft with tight process allowlists; widen only after Monitor shows stable behavior.

Read next

• Sandbox guardrails
• ProcessFlow keystore
• MCP guardrails configuration
• Trace AI Agent
• Autonomic Agents
• Tenant skills user guide
• API key security best practices
• Security checklist

Questions? Open a support conversation from your tenant or continue in the Library for field-level reference. Security is a practice you maintain — Tealfabric gives you the controls to make that practice operable at the same place you run your processes and agents.