100xprompt is built to be safe to hand real work to. An agent that edits code and runs commands earns trust only if you stay in control. Every sensitive action passes through an approval model, execution is bounded, credentials stay on your machine, and the agent is guarded against leaking secrets. This page explains those layers and the controls admins have over them.

​
Understand defense in layers

Security in 100xprompt is not a single switch. It’s a stack of independent controls, each narrowing what can happen before an action reaches your system.
The layers are independent by design. Even if one is relaxed - say you pre-approve a class of edits - the others still apply. Denials always win, so a broad allow can never override a specific deny.

​
Layer 1 - Set the permission model

Safety starts with a permission model that governs what the agent may do, tool by tool. Each capability - reading files, editing, running shell commands, fetching from the web, launching subagents - maps to a permission with one of three outcomes.
ActionMeaning
allowThe agent may proceed without interruption.
askThe agent pauses and requests your explicit approval first.
denyThe action is blocked outright - no prompt, no exception.
Rules target specific patterns, so you allow safe commands and still require approval for risky ones. Read-only inspection runs freely; anything that deletes files or touches a sensitive path requires a prompt. 
{
  "permission": {
    "read": "allow",
    "edit": "ask",
    "bash": {
      "git status": "allow",
      "git *": "ask",
      "rm *": "deny"
    },
    "webfetch": "ask"
  }
}
Permission rules live in your 100xprompt.json and can be set at the organization, project, or agent level. See Permissions for the full rule syntax and patterns.

​
Switch permission modes

Beyond static rules, a session runs in a mode that shapes how strictly approvals are enforced. Dial the interaction up or down for the task at hand.
ModeBehavior
DefaultUses your configured rules exactly as written.
Accept editsAuto-approves file edits so you can move fast, while other actions still follow policy.
PlanRead-only investigation - the agent can explore and reason but cannot change files or run commands.
AutoSafe actions proceed automatically; anything risky still asks. It can only relax an “ask” to a proceed - it can never override a deny.
There is also a bypass mode that auto-approves everything. It is intentionally not part of the normal mode cycle and must be enabled deliberately. Reserve it for trusted, isolated environments only.

​
Layer 2 - Approve sensitive actions

Suppose the agent is about to run a command you’d rather see first. When a rule says ask, the agent stops and shows you exactly what it wants to do - the command, the file, or the request - before anything happens. You approve once, approve a whole class of similar actions, or decline. Nothing sensitive runs behind your back.
Because approvals are explicit and shown in full, there is always a clear record of what the agent was permitted to do - useful for review and for building trust with a new team.

​
Layer 3 - Bound command execution

Running commands is one of 100xprompt’s most powerful capabilities, so it’s also one of the most carefully governed. Execution is scoped and bounded, not open-ended.

Policy-gated

Every command is checked against your permission rules first. Patterns let you allow routine tooling while gating destructive or unfamiliar commands behind approval.

Scoped to your work

The agent operates within your project’s working directory by default, and reaching outside it is itself a permissioned action you can require approval for.

Bounded runs

Long-running and background commands are managed with limits so a task can’t run away unattended.

Read-only when you want

Plan mode lets the agent investigate thoroughly without the ability to execute anything that changes state.

​
Layer 4 - Protect credentials

The credentials 100xprompt uses to reach models and providers are stored locally on your machine - not in your project, and not in any file you would share.

Stored locally

Access tokens and keys live in your own local configuration directory - never inside the repository or a shared config file.

Restricted access

The credential store is written with restrictive, owner-only file permissions so other users on the machine cannot read it.

Sign-in or key

Authenticate with a provider sign-in flow or an API key. Organizations can point teams at managed access instead of personal keys.

Kept out of sessions

Credentials are not part of the conversation content and are not included when you share a session.
Never commit API keys into 100xprompt.json, AGENTS.md, or any file you distribute. Provide credentials through the authentication flow or organization-managed access so they stay in the protected local store.

​
Know what leaves your machine - and what stays

Clear data flow is central to trust. In broad terms:
  • Your credentials and access tokens.
  • Your files on disk (the agent reads them locally; only the context needed for a task is sent to the model).
  • Your configuration and rules files, unless you choose to share or publish them.
  • Long-term memory and any facts the agent remembers about how you work.
Sharing is always a deliberate act. You control whether sessions are shared manually, automatically, or not at all, and any shared session can be made private again.

​
Guard against leaking secrets

100xprompt avoids capturing sensitive material where it could later be exposed. Its long-term memory, in particular, is explicitly instructed never to store secrets or personal data, and stored facts are scrubbed of credentials as a second line of defense. API keys, tokens, passwords, credentials, private keys, connection strings, and personal contact and payment details are omitted entirely - not paraphrased or referenced. The same guard applies when a session leaves your machine: before a shared session is published, its content is scanned and high-confidence secrets are redacted automatically. Treat this as a safety net rather than a guarantee - review a session before sharing it widely.

Secrets excluded from memory

Durable memory captures how you work - not the secrets you happen to mention. Sensitive values are dropped, not remembered.

PII kept out

Personal contact and payment details are treated the same way and excluded from stored facts.

Redacted before sharing

When you publish a session, its content is scanned and common credential shapes are stripped before it leaves your machine.

Credentials out of band

Because keys live in the protected local store rather than in conversation, they don’t end up in session content in the first place.

​
Set admin controls at a glance

Everything above is configurable. Admins set the guardrails once and roll them out across a team.
ControlWhat an admin can do
Permission rulesSet allow / ask / deny for each capability, with patterns for fine-grained gating.
Default modeEstablish how strictly approvals are enforced by default.
Command gatingAllow trusted tooling while requiring approval for destructive or unknown commands.
Directory scopeRequire approval before the agent reaches outside the project directory.
Model & provider limitsRestrict which models and providers the team may use.
Sharing policySet sharing to manual, automatic, or disabled organization-wide.
Deployment choiceRun managed or self-managed to control where work happens and how data flows.
Because these controls live in configuration your organization owns, you author your security posture once and apply it consistently - regardless of whether teams run 100xprompt managed or self-managed. See 100xprompt for teams & enterprise.

​
Follow these best practices

Begin with ask for edits and commands, watch how the agent works in your codebase, and relax specific rules as you build confidence - rather than starting permissive.
Use explicit deny rules for irreversible or destructive commands. Denials always win, so this is a hard backstop regardless of mode.
When you want the agent to investigate or propose an approach without any risk of change, run in plan mode - it can read and reason but not act.
Authenticate through the sign-in flow or provider keys, never by embedding secrets in shared configuration or rules files.
A shared session shows the full conversation. Make sure it doesn’t contain anything you wouldn’t want a wider audience to see before distributing the link.

Permissions

Author the allow / ask / deny rules that anchor the safety model.

Teams & enterprise

Roll security policy out across your whole organization.

Memory & context

How the agent remembers your workflow - and what it deliberately doesn’t.