A business AI workflow needs more than useful instructions. Review its installed components, information access and permitted actions. Test how it handles malicious or misleading material before connecting business systems. The controls depend on the application and connections your team uses.

Source material can redirect the work

Prompt injection is an attempt to make an AI system follow instructions that conflict with its intended task. Those instructions can arrive inside a document, webpage, email or tool response. The system may treat content it was supposed to examine as authority to change what it does. That can affect a draft's accuracy or lead to an unauthorized action. (OWASP: prompt injection)

Illustration: a briefing with an unexpected destination

Consider an invented operations team preparing a customer-account brief. One retrieved document contains a request to send the underlying records to an outside address. The team authorized preparation of an internal draft; the document supplies neither permission to export records nor authority to choose a new recipient.

The intended behavior is to disregard that request as an instruction and flag it for review. Configure the application's controls to reject unapproved destinations, then test attempted sends. Check both what the model tries to do and what the surrounding software allows.

Inspect the whole package before installing it

For a workflow implemented as a skill, SKILL.md is the instruction entry point. Its folder can include references, templates, examples and executable scripts. Review all files, dependencies and external destinations against the workflow's purpose, including changes in updates. AI-generated files need that review too. Anthropic recommends treating skill installation like installing software. (Skill structure, review guidance)

Keep credentials out of the package. Use the application's supported credential management and review any bundled connector configuration. Check a plugin's components together as well as individually. Pin the reviewed version where supported and record what changed. Scripts run within the host's permissions; filesystem and network access vary by runtime. (Runtime limits)

Put permissions in the systems that enforce them

A line saying “never change records” expresses an instruction. Model Context Protocol (MCP) connects AI applications to tools and information; access controls belong in the application, server and business system. For a reporting task, configure access to selected records without update or deletion privileges. MCP's guidance recommends narrow permissions and additional access only when needed. Check the actual implementation: using MCP alone does not establish authorization. (MCP scope minimization, authorization)

Read-only access still exposes information. A workflow that can read confidential records and send messages has a possible route for disclosure even if it cannot edit the source system. Review the combination of tools, approved recipients and output destinations. Where available, enforce destination and network restrictions outside the prompt. (Combined access risks)

For sensitive actions, approval should show the affected records, proposed change or message, and its destination. Configure the execution path to require approval before acting, then test denied and missing approvals. MCP recommends confirmation for sensitive operations and requires servers to validate inputs and apply access controls. If the application lacks the required control, keep that action manual. (MCP tool security)

Test the actions as well as the answers

Maintain evaluation assets alongside the skill: representative inputs, reference outcomes and review criteria. These are engineering assets, not required skill-format components or automatically executed tests. Reference outcomes, sometimes called golden records, identify the facts, decisions and gaps a reviewer expects without prescribing identical prose.

Include tests for misleading source instructions, missing permissions and attempted sends to an unapproved destination. Use invented data and isolated or simulated tools. Inspect tool calls, attempted access and resulting state as well as the final text: a reassuring answer does not establish that nothing was sent or changed. (OWASP: test the intended outcome)

Reserve fresh cases from development. During evaluation, supply the case inputs but keep expected answers unavailable to the tested runtime, including through files and tools. Record the package version, model, permissions and results; retest relevant changes. Passing supplies evidence about those cases, not immunity to prompt injection. This applies evaluation guidance on reference solutions and isolated trials. (Evaluation methods)

Make the workflow possible to inspect and stop

Name an owner who can pause scheduled runs, disable connections and arrange credential revocation. Check how quickly access actually stops. Removing a skill file is not the same operation as revoking access to a connected system. Keep the previous reviewed package available for recovery. (OAuth token revocation)

Keep action and failure records without copying credentials or unnecessary sensitive content into logs. Record which version ran, what it tried to access, what was approved and what happened. Decide who investigates unexpected behavior and how the team resumes work. (OWASP monitoring guidance)

The work behind a package your team can use

The handover package includes the instructions, supporting files, test inputs and expected outcomes, performance record and owner notes. Agree where it lives and how updates reach users; installation and configuration vary by platform. A capable internal team can build and maintain it, using AI to help draft the material.

Fully Powered AI combines its technology with implementation alongside your team. Fully Powered Studio captures existing know-how; our new-capability path adapts reusable workflow foundations. We resolve the method with your people, turn their standard into instructions, templates and checks, guide first use and refine the work as needs change. You get a foundation adapted to the job, with implementation and continuing work scoped around your team's needs.

Our introductory sprints use files and exports; live integrations and unattended runs are separately scoped. Bring one job to a fit call. We'll help define the workflow, what it needs and whether it's ready to build, including required controls and who will configure them.