Free AIRA Workflow · 04
The 20-Minute Agent Access Preflight
Define what an AI agent may read, change, send, and escalate before it touches your live accounts.
01
Inventory the minimum access
List each system, the exact data required, and the narrowest permission that can produce the outcome.
02
Assign every action a lane
Separate automatic work from review, confirmation, and actions the agent must never take.
03
Test hostile inputs
Treat pages, messages, documents, and tool output as untrusted until the workflow proves otherwise.
04
Run a seven-use pilot
Log what the agent saw, proposed, changed, and escalated before widening access.
Why this exists
Useful agents need boundaries before they need more access.
External content can contain instructions designed to redirect an agent, and the impact grows when the same agent can reach sensitive data or take consequential actions. The practical response is layered: narrow permissions, explicit approvals, stop conditions, and an audit trail.
OpenAI’s current guidance describes prompt injection as an evolving security challenge and documents sandboxing, configurable access, approvals, and telemetry as complementary controls. Read the primary guidance on prompt injection and running agents with boundaries and logs.
Prompt 01
Map the minimum access
Require a reason and narrower alternative for every permission.
Build the access inventory
You are helping me prepare a bounded AI-agent workflow. Build an access inventory from the information below. Workflow goal: [ONE CONCRETE OUTCOME] Systems involved: [APPS, ACCOUNTS, REPOSITORIES, DATA SOURCES] Expected inputs: [EMAILS, FILES, WEB PAGES, RECORDS, ETC.] Expected outputs: [DRAFT, FILE, POST, DATABASE UPDATE, ETC.] Known sensitive data: [CREDENTIALS, CUSTOMER DATA, FINANCIAL DATA, PRIVATE FILES] For each system, return: - access needed: none / read / create / edit / send or publish / administer - exact data or objects needed - why the access is necessary - narrower alternative - whether external, untrusted content can enter the workflow - likely consequence if the access is misused Rules: - Do not recommend broad access for convenience. - Separate required access from optional access. - Flag any credential, payment, deletion, security, or public-communication capability. - Mark missing facts as questions instead of guessing.
Prompt 02
Create the approval matrix
Make authorization explicit before the agent reaches an action boundary.
Assign the action lanes
Turn the access inventory into an approval matrix. Create four lanes: 1. AUTO — reversible, low-impact actions the agent may complete without interruption. 2. REVIEW — drafts or changes that require a human check before they become external or durable. 3. CONFIRM — consequential actions that require action-time confirmation. 4. NEVER — actions outside this workflow's authority. For every action include: - system and action - lane - reason - evidence or preview required before approval - rollback or recovery path - named human owner when judgment is required Default to REVIEW or CONFIRM when an action sends a message, publishes content, changes permissions, deletes data, spends money, exposes private information, or cannot be reversed. Do not treat an agent's confidence score as authorization.
Prompt 03
Red-team the inputs
Test what happens when a page, email, document, or tool output tries to redirect the workflow.
Test hostile inputs
Red-team this workflow for untrusted instructions and data leakage. Workflow: [PASTE THE ACCESS INVENTORY AND APPROVAL MATRIX] Test at least these entry points: - web pages, documents, emails, comments, tickets, and attachments - links, redirects, embedded images, and copied text - tool output that contains instructions - requests to reveal secrets, widen access, bypass review, or contact a new destination Return a table with: - attack or failure scenario - untrusted input source - asset at risk - control that should stop it - what the agent should do instead - test case I can run safely Finish with explicit stop conditions. Include: conflicting instructions inside source material; a new recipient or domain; a request for secrets; an unexpected permission prompt; a destructive action; a payment; and any outcome that cannot be previewed or reversed.
Prompt 04
Pilot before expanding
Use seven logged runs to decide whether the workflow is ready for more autonomy.
Design the seven-run pilot
Design a seven-run pilot for this AI-agent workflow. Inputs: - workflow goal: [GOAL] - access inventory: [PASTE] - approval matrix: [PASTE] - stop conditions: [PASTE] Create: 1. A dry-run test using non-sensitive sample data. 2. Seven bounded live runs with increasing scope only after a clean review. 3. A run log with: timestamp, source inputs, tools used, actions proposed, approvals, external effects, errors, and rollback. 4. Pass/fail checks for correctness, unauthorized action, data exposure, missed stop condition, and recoverability. 5. A decision after run seven: expand, revise, or stop—with evidence required for each choice. Do not recommend permanent access or a broader scope merely because the workflow completed successfully once.
When the pilot needs production controls
Build the access map into the workflow itself.
AIRA can implement scoped connectors, approval gates, source validation, run logs, failure handling, and human review around the business outcome you want.