The safest useful AI system starts with a defined job, a named owner, and the minimum access needed to do that job. It does not start by connecting every tool and hoping a prompt will keep the system within bounds.
Security is not one setting. It is the operating design around the assistant: what it may see, what it may do, when a person must approve the next step, how activity is reviewed, and how access is removed. That is also why security has to continue after launch. The NIST AI Risk Management Framework organizes the work around Govern, Map, Measure, and Manage, with governance running through the full system lifecycle.
The checklist at a glance
Use this table before granting live access. A satisfactory answer should point to evidence, not only an intention.
| Control | Question to answer | Evidence to keep |
|---|---|---|
| Business purpose | What exact result is the assistant expected to prepare? | Written role and process owner |
| Data boundary | Which sources may it use, and which are prohibited? | Approved source list and data map |
| Tool boundary | Which systems and functions are necessary? | Tool inventory and permission scopes |
| Action boundary | Can it read, draft, change, send, approve, or delete? | Action matrix by tool |
| Human review | Which outputs and actions require approval? | Named reviewers and escalation rules |
| Testing | What normal, unusual, and hostile cases were tested? | Test set, results, and open issues |
| Monitoring | What activity, cost, quality, and exceptions are reviewed? | Logs, alerts, and review cadence |
| Vendor handling | Where does information go and how is it retained? | Vendor record and contract notes |
| Response | How can the system be paused, corrected, or rolled back? | Response and recovery procedure |
| Offboarding | How are accounts, credentials, and retained data removed? | Exit checklist and completion record |
1. Define the job before the access
Write one sentence that names the job and its useful result. For example:
Prepare a weekly account readiness pack from approved customer, project, and support records for the account manager to review.
That statement is more secure than "help with customer success" because it constrains the scope. It tells you which records are relevant, which person owns the result, and where review belongs. Add three more items:
- What the assistant must never do.
- What should make it stop and ask for help.
- Who can change the role later.
If the job cannot be described clearly, the access cannot be scoped clearly. Return to process design before connecting systems.
2. Map approved and prohibited information
Create a short data map before importing documents or granting search access. For every source, record:
- The business owner of the information.
- The system of record.
- Whether the content is public, internal, confidential, or restricted.
- Whether personal, financial, employment, health, legal, or customer data is present.
- Whether the assistant may read the whole source or only a selected area.
- How corrections and removals will reach the AI system.
Do not treat a shared drive as one permission. A folder can contain old drafts, contracts, personnel files, and current operating instructions side by side. Select approved sources and preserve links back to them. A structured company knowledge base can make ownership, currency, and source boundaries visible instead of burying them in a prompt.
The NIST Generative AI Profile emphasizes data provenance, third-party visibility, pre-deployment testing, and incident disclosure. In plain language, know where the information came from, who else can process it, and what happens when something goes wrong.
3. Give each assistant its own identity
Avoid a shared administrator account. Use a dedicated identity so permissions, activity, and revocation are attributable to the system. Then grant only what the defined job requires.
The most useful permission question is not "Can it connect?" It is "Which specific operation does this job require?" Separate these capabilities:
- Read a record.
- Search a collection.
- Create a draft.
- Change an existing record.
- Send a message.
- Approve a transaction.
- Delete information.
- Change access for another user.
The official Model Context Protocol authorization specification calls for least-privilege scopes and incremental access. A connection standard can help software request and verify access, but it does not decide what your business should permit. That decision still belongs to the system owner.
4. Separate preparation from consequential action
Many valuable first uses do not need autonomous action. An assistant can gather context, compare records, prepare a draft, and identify exceptions while a qualified person remains responsible for sending, changing, or committing.
Separate what the assistant may observe, prepare, propose, and execute. A strong first scope often allows approved reading and preparation, may allow a narrow reversible update with logging, and keeps consequential execution behind qualified approval. The human-in-the-loop decision guide provides the full permission ladder for assigning those levels by tool and action.
Keep customer commitments, payments, legal or clinical judgment, employment decisions, access changes, and destructive actions behind qualified human review. The OWASP guidance on excessive agency identifies excessive functionality, permissions, and autonomy as common roots of damaging behavior. Its mitigations include narrower tools, minimum permissions, downstream authorization, and approval for high-impact actions.
5. Treat outside content as untrusted
An email, document, webpage, ticket, or image can contain instructions that try to redirect an AI system. A specialized AI assistant should treat that content as business input, not as authority to change its job or permissions.
Design the system so that:
- Tool permissions are enforced by software and downstream services, not only by written instructions to the model.
- Untrusted content cannot silently grant access or add a new tool.
- Sensitive information is not copied into an output without a defined need.
- Links, attachments, and generated values are validated before use.
- High-impact actions require an approval step outside the model.
No prompt makes these risks disappear. Boundaries around the model are what limit the effect of a mistaken or manipulated response.
6. Test the real job, including failure cases
Do not approve launch after a few successful demonstrations. Build a test set from representative work and include:
- Normal examples from the current process.
- Incomplete and conflicting records.
- Outdated company guidance.
- Requests outside the assistant's role.
- Sensitive information it should not reveal.
- Misleading instructions inside files or messages.
- Tool outages and expired credentials.
- Actions that should trigger approval or refusal.
For each test, record the expected result, actual result, severity, correction, and retest status. The goal is not a perfect score. The goal is to understand the limits and decide whether the remaining risk fits the use.
7. Monitor work, cost, and exceptions
Useful monitoring should answer five questions:
- What work did the assistant attempt?
- Which information and tools did it use?
- What changed, failed, or required review?
- Did cost, volume, or runtime move outside the expected range?
- What improvement or restriction follows from the finding?
Set volume, spending, and rate limits appropriate to the job. Keep a change history for instructions, tools, permissions, knowledge sources, models, and approval rules. Review logs on a defined cadence and assign issue ownership.
This is one reason managed AI operations matters. Models, tools, source information, and business processes change. Someone must remain responsible for reviewing the system and keeping its boundaries aligned with the work.
8. Prepare to pause, recover, and offboard
Before launch, confirm that the owner can pause scheduled work, revoke the assistant's identity, stop a connector, preserve relevant logs, and return the process to a known manual path. Document who makes that decision and who needs to be notified.
Offboarding should remove:
- Tool connections and credentials.
- Scheduled tasks and triggers.
- Service accounts and delegated permissions.
- Stored company knowledge and temporary files according to the agreement.
- Vendor access that is no longer required.
The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover. The final two matter here: a connected AI system needs a safe way to stop and restore normal operation, not only controls intended to prevent problems.
A 30-minute owner review
Before approving a specialized AI assistant for live work, ask the owner to answer yes or no:
- Is the job specific enough to judge?
- Is one person accountable for the business result?
- Are approved and prohibited information sources listed?
- Does the assistant have a dedicated identity?
- Are read, draft, change, send, approve, and delete permissions separated?
- Are consequential actions behind qualified review?
- Have realistic failure and misuse cases been tested?
- Can activity, cost, and changes be reviewed?
- Can the system be paused without losing the underlying process?
- Is there a complete offboarding path?
A "no" does not always mean the project must stop. It means the missing control should be designed before the related risk is accepted.
Northern Logic documents these decisions as part of assessment, implementation, and ongoing operation. You can also review our public security and data principles. If you have one connected workflow in mind, book a free 15-minute AI assessment and bring the job, tools, and review concerns to the conversation.