The useful version of an AI agent can read the current project, answer from the approved specification, and put an update where the team will see it. The uncomfortable part is not capability. It is access.
Give an agent no company context and it fills the gaps with general knowledge or inference. Give it a broad administrator token and a routine prompt can reach payroll documents, private customer notes, or production controls it never needed. The choice is not “useless agent” or “agent with everything.”
The practical pattern is least-privilege context: give each agent its own identity, the smallest useful scope, a bounded set of operations, and more friction as the consequence of an action increases.
This article lays out that pattern from connection to rollout.
Start with the job, not the model
“Connect an AI agent to our workspace” is too broad to secure or evaluate. A job is specific:
Every weekday, summarize changes and blockers on the Website Launch board, citing the underlying tasks. Do not update anything.
That sentence gives you a permission boundary and a success test. The agent needs:
- read access to one board;
- access to task status, owners, comments, and dependencies;
- a retrieval or search operation;
- no write operations; and
- a destination for the report.
It does not need the entire project-management account, private documents, or the ability to delete a task. Beginning with the job makes least privilege a design input instead of a security cleanup.
The seven controls that make agent access governable
Safe agent access is not one toggle. It is a chain of controls. A weakness in one layer should not automatically expose everything behind it.
1. A separate identity
Do not reuse a person’s permanent token. Issue a dedicated credential for the agent or workflow. A separate identity can be scoped, observed, rotated, and revoked without disrupting its owner’s account.
Name it after the job—website-status-reporter, not ai-key-3. Ownership and
purpose should be obvious months later during an access review.
2. Resource scope
Define where the identity can operate: organization, space, project, board, document collection, feedback portal, or meeting library. Narrower is usually better, provided the scope still contains the context required for a correct answer.
Scopes should be positive grants. “May access the Website Launch board” is easier to reason about than “may access everything except these nine spaces.”
3. Capability scope
Define what the identity can do inside that resource. Search, retrieve, create, update, comment, export, and delete are different capabilities.
Read and write should always be separable. For writes, prefer purpose-built
tools such as create_task with validated fields over a generic operation that
can mutate arbitrary records.
4. Permission-aware retrieval
The underlying permission model must be applied before results enter the model’s context. Filtering the final prose is too late: the model has already seen the material and may expose it indirectly.
In Dutify, scoped keys are filtered at query time by the same View / Edit / Admin model used for people. An agent sees granted spaces and boards, and drafts are excluded. The important principle is enforcement at retrieval time, not reliance on a system prompt that says “do not reveal secrets.”
5. Bounded context
Return the smallest set of passages and structured facts that can answer the question. Include source identity, state, timestamps, and citations. Do not pour an entire workspace into a prompt simply because the credential permits it.
Bounded context improves security, but it also improves answer quality. The agent has less irrelevant material to reconcile and a clearer basis for saying what it knows.
6. Approval matched to consequence
Not all writes carry the same risk. Drafting a task in a review queue is different from emailing a customer. Updating a label is different from deleting a project.
Use a progression:
- read for low-risk reporting and research;
- propose for actions a person should inspect;
- execute with approval for consequential or external changes; and
- automatic execution only for narrow, reversible, well-observed actions that have earned trust.
7. Audit and revocation
Record the identity, query, sources retrieved, tool invoked, target, approval, and outcome. Keep an immediate revocation path. When something goes wrong, the team should be able to answer “What did it see and change?” without reading application logs from five systems.
One door is easier to govern than ten hidden doors
An agent that needs work, docs, and feedback can be wired to each product separately. That may mean three credentials, three permission models, three result formats, and three places to audit. The agent—or the code around it—then has to decide how those systems relate.
A shared agent surface provides one connection and a consistent set of tools, while the source products retain their own object models and permissions. Dutify exposes work, docs, and feedback through MCP and an AI-native API. A scoped key can search, retrieve, create, and update within its grants; the live API catalog makes the available tools inspectable.
One door should not mean one master key. The connection is unified; the scopes remain specific to the agent’s job.
MCP is useful here because it gives compatible agents a standard way to discover and invoke tools. It does not remove the need for authentication, authorization, validation, or approval. A protocol can describe a door. Your permission model still decides what lies behind it.
Design scopes around agents, not around vendors
Keep the agent you already use—whether that is Codex, Claude, Cursor, or an internal automation—and make the context credential independent of the model vendor. More importantly, issue different credentials for different jobs.
| Agent job | Resource scope | Capabilities | Approval |
|---|---|---|---|
| Stand-up reporter | One active project | Search and retrieve | None; read-only |
| Release-notes drafter | Release board + approved public docs | Read; create a draft page | Editor approves publication |
| Feedback triage assistant | One feedback portal + public docs | Read; propose tags and links | Triage owner approves batch |
| Customer follow-up assistant | Selected meeting library + CRM account | Read; draft external message | Account owner approves send |
This separation limits blast radius. It also makes output easier to evaluate: each identity has one purpose and a defined set of expected actions.
Avoid a long-lived “general assistant” key that slowly accumulates permissions for every new demo. If a new job needs a new scope, create a new identity.
Retrieval must be built for grounding
Raw exports are a poor default context format. Good agent retrieval combines text passages with operational metadata:
- source and canonical link;
- object type and parent location;
- current status or publication state;
- owner and relevant dates;
- version or last-updated time;
- relevance signal; and
- the relationship to other retrieved objects when known.
Suppose the agent is asked, “What did we decide about the Q3 pricing page?” A grounded response might need the active implementation task, the approved page section, the customer request that drove the change, and the latest meeting decision. Each claim should cite the object it came from.
If retrieval finds conflicting sources, the agent should expose the conflict:
The active task targets August 18, but the release meeting on August 4 moved the target to August 21. The task may be stale.
That is more useful than choosing whichever passage scored higher and presenting it as certainty.
Threats to consider before the first connection
Least privilege protects more than confidential folders. Model-connected tools introduce specific failure modes.
Prompt injection in retrieved content
A document, feedback submission, or web page can contain text that tells the agent to ignore instructions or invoke a tool. Treat retrieved content as data, not authority. Tool policies and approvals should live outside the retrieved text, and high-risk actions should not be reachable solely because a document requested them.
Excessive agency
A broad goal such as “keep the project on track” gives the agent too much room to decide which changes are appropriate. Prefer explicit tasks, bounded tools, limits on affected records, and approval for irreversible or external effects.
Stale authority
A credential created for a short experiment can become permanent infrastructure. Set an owner and review date. Rotate keys, remove unused identities, and make temporary access expire when possible.
Cross-context leakage
An agent serving several teams may accidentally carry information from one run into another through logs, memory, caches, or conversation history. Separate identities and execution contexts when scopes or audiences differ.
Confused approval
An approval screen that says “Allow update?” is not informed consent. Show the target, exact fields, previous and proposed values, affected audience, and whether the change can be undone.
A rollout that earns broader access
The safest rollout is also the easiest to debug.
Phase 1: read one maintained source
Choose a real, narrow job and one source with an accountable owner. Run the agent read-only. Require citations and compare its output with the underlying records. Measure missing and incorrect claims, not just whether the prose is pleasant.
Phase 2: add the minimum surrounding context
When errors come from missing information, add only the source that resolves them. If a status agent needs the approved specification to interpret a task, grant that collection—not the entire wiki.
Phase 3: propose writes
Let the agent draft a task, comment, or page without committing it. Capture what reviewers change. Repeated corrections reveal whether the prompt, source data, or tool schema needs work.
Phase 4: execute approved actions
Connect the review to execution so the approved payload—not a regenerated version—is what gets written. Log the result and return a direct link to the changed object.
Phase 5: automate only the boring, reversible part
After a stable history, consider automatic execution for narrow operations with clear rollback. Keep sampling outcomes and preserve a kill switch. Trust should expand because evidence supports it, not because the pilot has been running for a month.
A preflight checklist
Before an agent touches team context, confirm:
- The job and expected output are written in one or two sentences.
- The agent has its own named identity and owner.
- Resource access is positively scoped to the smallest useful set.
- Read, create, update, and delete are separate capabilities.
- Permissions are applied before retrieval reaches the model.
- Results include citations and enough metadata to evaluate freshness.
- Retrieved content cannot independently authorize a tool action.
- Consequential writes show an exact preview and require approval.
- Queries, sources, approvals, actions, and failures are logged.
- The credential can be rotated and revoked without affecting a person.
- The scope has a review or expiry date.
- Someone owns correction when the agent is wrong.
Begin with one agent and one scope
A read-only reporting agent on a single board is a strong first deployment. It solves a real job, makes grounding visible, and creates little blast radius. If it cannot produce a reliable cited report from that boundary, broader access will not fix the underlying problem.
Once the output earns trust, expand deliberately: one additional source, one proposed action, one approval path at a time.
Connected agents become useful when they share the team’s current context. They become governable when that context has boundaries. The architecture you want is not an omniscient assistant. It is a set of well-identified workers, each able to see and do exactly enough for the job—and no more.