Contractor Access to a Company AI Agent: Time-Boxed Rules

Give contractors and temp staff access to a company AI agent through a separate, time-boxed role: a named sponsor, a short list of approved tasks, a limited set of tools and documents, and an end date that closes access on its own. Treat the agent's memory as a company asset that contractors may use for their work but not take with them. When the engagement ends, review what they did and decide what stays.

Key takeaways

• Create a contractor role that is separate from employee roles, with its own tools, documents and approval limits, rather than copying an employee's access.
• Every contractor account needs an owner inside the company, an end date set on day one, and no shared logins.
• Split memory into company memory (read only for contractors), engagement memory (scoped to the project) and personal session memory (discarded or handed over at the end).
• Anything with outside effects, such as sending messages, changing records or spending money, needs an employee's approval.
• Offboarding is part of the design: revoke access, review the engagement memory, promote what is useful and archive the rest.

Why do contractors need different rules from employees?

An employee has a manager, a contract with no fixed end, a history in the company and, usually, years of context about what is sensitive. A contractor or temp worker often has none of that on the first morning. They may work for several clients, use their own devices, and leave in a few weeks. None of this makes them untrustworthy. It means the company cannot rely on habits and shared understanding to do the work that rules should do.

An AI agent sharpens the problem. A well-run agent has memory, connected tools and the ability to act in your channels. Those are exactly the things that make it useful, and exactly what you do not want to hand over wholesale to someone who will be gone by the end of the quarter. Without explicit rules, the common outcome is a contractor logging in with a colleague's account, or being given the same access as the person they replace because that was the fastest path.

The guiding idea comes from general authorization practice: grant the minimum needed for the task, deny anything not explicitly allowed, and check permissions on every request instead of once at login. For an agent, that applies in three places: what the person can ask, what the agent can reach on their behalf, and what the agent remembers afterwards.

What should a contractor be allowed to do with the agent?

Start from the task, not from the person. Write down the two or three jobs the contractor was hired for and list which agent capabilities those jobs actually need. Everything else stays off by default.

A useful scope statement answers five questions:

• Which tasks may the contractor ask the agent to perform?
• Which documents, folders and systems may the agent read when acting for them?
• Which systems may the agent write to, and in what state (draft, suggestion or final)?
• Which actions need an employee's approval before they happen?
• Which channels may the contractor use to reach the agent?

Two details matter more than they seem. First, the agent should act with the contractor's scope, not its own broadest scope. If the agent can read the whole finance folder but the contractor may only see the project folder, the agent must answer the contractor from the project folder only. Delegated access in modern authorization systems works the same way: a token carries specific scopes, and the service enforces them. Your agent setup should mirror that idea even if you never touch the technical protocol.

Second, the contractor should not be able to change the agent. Instructions, tool connections, memory rules and approval limits belong to the company. If a contractor wants a different behavior, they ask their sponsor, who can raise it through the change request process. Which settings stay with business owners is covered in Which AI Agent Settings Should Business Owners Control?.

Also consider that contractors bring documents with them: briefs, client files, scraped pages. Any outside text the agent reads can contain instructions aimed at the agent, accidentally or on purpose. Guidance on prompt injection recommends treating such content as untrusted data, never as commands. In practice that means the contractor's uploads are handled in the engagement workspace, and the agent's ability to act on them is limited to what the role already allows.

How should memory work for people who are not employees?

Memory is where contractor access most often goes wrong, because it is quiet. Nobody sees what the agent has learned about a project until it surfaces later in someone else's answer. Decide in advance where contractor-related information lives and who owns it.

A three-part model works for most companies:

• Company memory: policies, product facts, style guides, approved templates. Contractors can read the parts relevant to their role. They cannot add to it or edit it.
• Engagement memory: a workspace for this contractor's project, holding briefs, drafts, decisions and notes. The contractor and the sponsor can use it. It carries a label for the project and an end date.
• Session memory: the contractor's own conversation context. It helps during the work and is not carried forward by default.

The rule that holds the model together: nothing moves from engagement memory into company memory without a named employee reviewing it. This protects you from two opposite failures. One is losing valuable knowledge when the contractor leaves. The other is quietly absorbing half-correct notes, personal preferences or a previous client's material into the memory everyone else relies on.

It also helps to be explicit about what the contractor may not ask the agent to remember: other clients' confidential information, credentials, personal data unrelated to the task. The agent can be instructed to decline, and your contractor agreement should say the same thing in plain terms.

If the contractor works across several of your teams, give each team its own engagement workspace. One shared workspace for a person who touches sales, finance and support recreates the very overreach you are trying to avoid.

What is a practical onboarding plan for a contractor?

The plan below fits a single contractor or a small group of temp staff. It assumes the agent already has a working permission structure. If you have not reviewed that structure recently, do so first, using How to Run a Permission Review for Your AI Agents, Step by Step.

• Step one: Name the sponsor. One employee is accountable for the contractor's use of the agent, approves their requests and signs off at the end.
• Step two: Write the scope statement. Use the five questions above and keep it to one page that the contractor can read in a few minutes.
• Step three: Set the end date before anything else is configured. Use the contract end date, with a short review window after it. Extensions are a deliberate decision by the sponsor, not a default.
• Step four: Create an individual identity. No shared logins and no borrowed employee accounts, so every action traces back to a person.
• Step five: Assign the contractor role. Attach only the tools, documents and channels from the scope statement.
• Step six: Set approval rules. Define which outputs are drafts the contractor can use freely and which actions wait for an employee.
• Step seven: Open the engagement workspace. Label it with the project and the end date.
• Step eight: Brief the contractor. Cover what the agent can do, what it will refuse, how to report problems, and what happens to their work at the end.
• Step nine: Check in at the midpoint. Look at the activity record with the sponsor and adjust the scope if the real work differs from the plan.
• Step ten: Close out on the end date, using the checklist in the offboarding section below.

The brief in step eight is easy to skip, and skipping it creates friction. People who do not know why a request was declined tend to look for a workaround. A short explanation of the boundaries does more than any restriction on its own. For wider guidance on helping people use the agent properly, see How to Get Your Team to Actually Use an AI Agent.

Decision guide: how much access fits which kind of worker?

Not every outside worker needs the same treatment. Use this list as a starting point and adjust it to your own risk tolerance.

• Short-term temp doing a repeatable task (for example, data entry support or document sorting): read access to a single folder, a fixed set of task templates, all outputs reviewed by an employee, access ends with the shift contract.
• Project contractor with a defined deliverable (for example, a researcher or designer): engagement workspace, read access to relevant company memory, draft-only writing, sponsor approval for anything leaving the company.
• Embedded contractor working alongside a team for months: a contractor role close to an employee role but still without administrative rights, a periodic access review, and a renewal decision rather than automatic continuation.
• Agency or outside firm with several people: one role per person, one sponsor for the whole group, and a clear rule that credentials are never shared inside the agency.
• Advisor or auditor who needs to inspect the agent itself: read-only access to configuration and activity records, no ability to change them, and a clear statement of what they may copy.

Illustrative scenario: a company brings in a bookkeeper for a three-week month-end cleanup. The sponsor is the finance lead. The scope allows the agent to read the reconciliation folder, draft journal explanations and flag mismatches. It does not allow the agent to post entries or message suppliers. The bookkeeper works in an engagement workspace. In the midpoint review, the sponsor notices the bookkeeper keeps asking for a vendor contact list that is outside the scope. The sponsor decides to supply the two relevant contacts directly rather than widen access. At the end, the finance lead reviews the workspace, promotes a corrected reconciliation checklist into company memory, and archives everything else.

What happens on the last day?

Offboarding is the part most companies improvise, and it is the easiest to make routine. Because you set an end date on day one, the system can close access automatically, and the sponsor handles the human part.

Use this checklist:

• Confirm that the contractor's identity, tokens and channel access have been revoked, and that no connected tool still holds a session for them.
• Review the activity record for the engagement: what was asked, what was produced, what was approved.
• Read through the engagement memory and mark each item as promote, archive or delete.
• Promote reviewed, accurate items into company memory under a named owner.
• Archive the rest with the project label so it can be found if there is a dispute or an audit, and set a retention date.
• Ask the contractor to hand over any work in progress through the agreed channel, not by exporting memory.
• Record any lessons for the next engagement: scope that was too narrow, scope that was too wide, tasks the agent handled poorly.

Keep a short window after the end date for questions, but do not leave access open to cover it. If the company needs the contractor for a follow-up, that is a new engagement with a new end date. For a wider view of how such routines fit into a company-wide approach, AI Governance for Companies: A Lightweight Start for Mid-Sized Firms is a useful companion.

How does Be Human handle contractor access?

Be Human designs the contractor role as part of the agent's initial setup: identity, memory structure, tools, permissions and approval boundaries are defined with the company's owner, and the contractor role is one of the roles defined there. In managed operations, Be Human monitors activity against the agreed scopes, supports the recurring permission review, helps close expired access, and applies changes only after the company approves them. The company keeps control of who is a sponsor, what each role may do and what is promoted into company memory.

Frequently asked questions

Should contractors use the same agent as employees, or a separate one? In most cases the same agent with a separate role is enough, as long as the role limits tools, documents, memory and approvals. A separate agent makes sense when the contractor works with data that must be kept apart from the rest of the company, or when an outside firm needs its own environment. Decide based on how different the data and actions are, not on how many people are involved.

Who should be able to extend a contractor's access? Only the sponsor, and only with a recorded reason and a new end date. The extension should be visible to the person who owns the agent's permissions, so that open-ended access does not accumulate unnoticed. If extensions are frequent, that is a sign the contract or the role needs rethinking.

Can a contractor see what the agent remembers about other people's work? Not by default. The contractor sees company memory relevant to their role and their own engagement workspace. Anything else, such as another team's notes or individual employees' conversations, stays out of reach unless the sponsor and the memory owner explicitly decide otherwise.

What should we do if a contractor leaves early or the relationship ends badly? Revoke access immediately instead of waiting for the planned end date, then run the usual review of the activity record and engagement memory. Because every action was tied to an individual identity, you can see what was done and decide what to keep. Involve whoever owns your legal and HR processes for anything beyond the agent itself.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.