Safe Actions in Production: How to Architect a Copilot That Won't Delete Your Database

SaaS CTOs are terrified of AI taking wrong actions—like refunding the wrong customer, changing a critical setting, or deleting a database. And frankly, they should be. Security is the #1 blocker to enterprise adoption of agentic AI.

The fear is valid: LLMs are probabilistic engines. They hallucinate. They can be "prompt injected." If you give an LLM a root API key and say "be helpful," you are inviting disaster.

So how do we build a system that allows an AI to be useful (take actions) without being dangerous? The answer lies in Architectural Constraints, not just "better prompts."

The Principle of Least Privilege for Agents

Just like you wouldn't give a junior intern database write access to production, you shouldn't give your AI agent broad permissions. At Touchstage, we enforce this through a multi-layered security architecture.

1. Tenant-Scoped OAuth: The First Wall

Think of Touchstage as a multi-tenant orchestrator that sits outside your product but connects into it using per-tenant integrations. We never use global backdoor keys or shared service accounts.

For each of your customers (e.g., "Acme Corp"), there is a distinct Tenant in Touchstage. Inside that tenant, we store "Connections" (like "Prod API", "Staging API", "Jira"). Each connection has its own credentials—usually OAuth tokens scoped specifically to Acme Corp's resources.

When the copilot acts "on behalf of Acme Corp," it:

1. Resolves "which tenant is this session from?"
2. Retrieves only the credentials associated with that specific tenant.
3. Executes the action.

The Result: Data simply cannot bleed across tenants. Even if the LLM hallucinated and tried to query data from "Globex Corp," the infrastructure physically blocks the request because it lacks the credentials to do so.

2. Step-Scoped Tokens: Limiting the Blast Radius

Even inside a single tenant, we don't want the model to have long-lived, overpowered keys. If an attacker somehow hijacked the agent's context, we want to limit the damage.

We use Step-Scoped Tokens. For each specific execution step (a single tool call), our system mints a short-lived, single-purpose token.

• Ephemeral: The token exists only for the duration of that one API call.
• Bound: It is cryptographically bound to the Tenant ID and the specific Capability ID (e.g., refund_user).

The LLM never sees the raw API keys. It just emits a structured command: execute_tool("refund_user", { amount: 20 }). Behind the scenes, our secure proxy validates the permission, mints the step token, injects it into the header, calls your API, and returns the result. The model acts as the reasoning engine, not the credential holder.

Guardrails & Fail-Closed Policies

Architecture handles authentication. But what about authorization logic? Is it "okay" to refund this user right now?

We implement Fail-Closed Policies. This means the default answer to any action is "No," unless a specific policy allows it.

Static Policies

These are hard rules defined in code or configuration. Examples:

• "Refunds under $50 are auto-approved."
• "Refunds over $50 require human review."
• "Only users with `role: admin` can delete projects."

Dynamic Policies

These depend on the state of the world. Examples:

• "Allow action only if the user has verified their email."
• "Rate limit: Max 5 invites per hour."

When the agent proposes an action, the Touchstage Policy Engine evaluates the request against these rules. If the payload violates a guardrail, or if the policy check fails, we block the execution.

Human-in-the-Loop: The Ultimate Safety Net

What happens when a request is blocked? We don't just say "Error." We route it to a Human-in-the-Loop queue.

If a user asks for a refund of $500 (violating the $50 auto-approve policy), the agent creates an approval request. A human support agent sees:

• The user's request ("I want a refund").
• The AI's reasoning ("User is unhappy with service").
• The proposed action (Refund $500).

The human can then click "Approve," "Reject," or "Modify." This creates a safe learning loop where sensitive actions are always supervised.

The Key Takeaway: In a production AI system, confidence is not enough. You need architectural guarantees. By separating reasoning (LLM) from execution (Touchstage Proxy) and enforcing policies at the infrastructure layer, you can ship agentic features without losing sleep over database deletions.