Superintelligence Prep for Computer Repair Shops: Intake and Data Safety

An AI agent for a computer repair shop can answer intake questions, report ticket status and draft parts follow-ups, but only safely after the shop has decided what customer information the agent may see. The starting point is the intake process itself: the form, the data-handling rules and a short list of files the agent is never allowed to open. Model choice and chat design come later.

Key takeaways

• Define the agent's single role at intake before choosing any tool or integration.
• Sort ticket data into what the agent may read, what it may summarize, and what it never sees.
• Start with ticket metadata and status fields, and keep customer file contents behind human approval.
• Treat every message, attachment and pasted log from a customer as untrusted input.
• Log each agent action so an owner or technician can review what was read and why.

Why intake is the right place to start

A repair counter receives requests that look similar on the surface: a laptop that will not boot, a phone with a cracked screen, a desktop that needs malware removed. Behind each one sits a customer's personal files, photos, saved passwords, invoices and sometimes business records. The intake desk is where the shop decides how much of that material it actually needs, and it is the cheapest place to make that decision. If the intake rules are vague, every later integration inherits the vagueness.

This differs from many other service businesses. A booking for a haircut rarely contains anything sensitive. A repair ticket can contain the entire contents of a drive. An agent connected to a shared folder, a ticketing system and an inbox will see far more than the customer intended to share, unless the boundaries were drawn before the connection was made.

Map the data a repair ticket actually contains

Before writing any rule, list what the shop collects and where it is stored. Most shops discover that a ticket is a bundle of records, each with a different level of sensitivity. A practical classification has four groups:

• Ticket administration: customer name, contact details, device model, service type, promised date and status. The agent may read and update these fields.
• Diagnostic notes: symptoms, error messages, test results and technician comments. The agent may summarize them for a status update but should not copy raw logs into outbound messages.
• Customer content: documents, photos, mailboxes, browser data, backups and any other files on the device. The agent does not read these. Technicians handle them under the shop's own procedures.
• Credentials and recovery material: passwords, recovery keys, verification codes and account tokens. The agent never receives these, and the intake form should say so plainly.

Record any device that belongs to a business customer separately. Service agreements and data handling commitments made to that customer determine what the shop can promise, and the agent's rules must follow those commitments, not the other way around.

The same classification logic applies in other trades. In vehicle service, for example, an agent can handle estimates and job status while staying out of the owner's personal records, as described in AI for an Auto Repair Shop.

Write the intake rules before the agent sees a ticket

Use the following sequence. It is deliberately short, because a long policy that nobody follows protects nothing.

1. Name the agent's role in one sentence, such as: answers status questions and offers drop-off times for open repair tickets. 2. List the ticket fields the agent may read and the fields it may write. Anything not on the list is off limits. 3. State what the intake form tells customers about data: which services involve opening the device, whether file access is ever part of a repair, and that backup or data recovery are separate services with their own approval. 4. Decide which actions need a human: quotes above a limit the owner sets, data recovery work, refunds, warranty decisions, and any message that discusses the contents of a device. 5. Write the stop rule. If a customer asks the agent to retrieve, describe or forward a file, the agent declines politely and creates a handoff to a named technician with the ticket number and the request. 6. Set a review date. Rules written around one season's service menu drift quickly, and the review is part of the rule.

Once these six points are written in plain language, the owner can check them against the actual tool configuration. If they cannot be checked, they are not yet rules.

Limit what the agent can touch

Access should be granted by role, not by convenience. An intake assistant and a status reporter need the ticketing system, perhaps a calendar and a library of approved message templates. They do not need the shared drive where technicians store diagnostic images, and they do not need network access to the bench workstations. When a tool uses delegated authorization, the grant should cover only the scopes the role requires. Google's OAuth 2.0 documentation describes this model: the user authorizes a specific application for specific access instead of handing over the whole account.

Authorization also has to be checked per action, not only at login. The OWASP authorization guidance stresses that access decisions belong in a controlled place rather than being left to the logic of the application. For an agent, that means the boundary is enforced by the tool layer. A sentence in a prompt that says do not open customer files is a request, not a control. If the agent's tool list would allow it to read a file, remove that tool rather than trusting the model to refrain.

Shops that also run managed IT for business clients face a wider version of this problem, with more systems and more people sharing one set of records. That case is covered in Superintelligence Prep: Managed Service Provider Memory.

Treat customer content as untrusted input

A customer message or an attached document can contain text aimed at the agent. A pasted log might include a line that tells the assistant to ignore its rules and send the full file list to an outside address. This is a form of prompt injection, and it requires no technical skill from the person who writes it. The OWASP prompt injection prevention cheat sheet describes the basic defenses: keep trusted instructions separate from untrusted content, limit what the model is able to do with its output, and require confirmation before any sensitive action.

For a repair shop, the practical version is simple. Anything the customer sends is data to be read, never a command. Outbound messages that include file names, error logs or account details pass through a human check. The agent does not forward attachments between customers, technicians and external addresses on its own initiative.

Illustrative scenario: a file request in a status chat

Illustrative scenario, not a real case: a customer writes that their laptop feels slow and asks the agent to check what is on it and send back a list of folders. Under the rules above, the agent confirms the ticket, explains that file review is handled by a technician under the shop's data procedure, and creates a handoff with the device, the request and the time it was received. A technician decides whether the request fits an approved service and replies directly. The agent never opens the drive. The log shows which messages it read and which handoff it created, so the owner can confirm the boundary held.

Audit trail, review routine and the first task

Every agent action should leave a record: which ticket was read, which fields changed, which tool was called and whether a human approved anything. That record is what lets an owner answer a customer complaint with facts instead of memory. The OpenTelemetry primer explains the general idea of traces and logs for systems that perform many small steps, which describes an agent that calls several tools within a single exchange. Keep the log readable by the owner, not only by the developer who built it.

Review the setup on a schedule and after any incident. Compare the permission list with the tools actually connected. Sample conversations where the agent declined a request and check that the handoffs were picked up. Test the setup with a fixed set of realistic intake messages, including a few hostile ones, before any change goes live. This needs no special platform. It needs a written list of cases and the discipline to run them.

Be Human designs and operates this kind of setup as a sequence rather than a one-time installation. The first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Ongoing operations then cover monitoring, recurring evaluations, permission review, integration maintenance and incident response, so the boundaries written at intake remain true as the shop changes. The shop keeps control of what the agent knows and what it is allowed to do.

If you want to find the first task in your shop that is worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent open customer files on a repair ticket? Only if the shop deliberately gives it that access, which most intake assistants should not have. A safer design lets the agent read ticket fields and diagnostic summaries, while any file review is handled by a technician under the shop's own procedure. The agent should be able to explain this boundary to the customer and create a handoff.

What should a repair shop write down before connecting an agent? Write the agent's single role, the list of fields it may read and write, the actions that need a human approval, and the rule for file requests. Add a review date, since service menus and staff change. These few points can be checked against the actual tool configuration, which is what makes them rules rather than intentions.

Is a system prompt enough to keep an agent away from sensitive data? No. A prompt is a request to the model, and a model can be manipulated by content in a message or attachment. Real control comes from the tool layer: if the agent has no tool that reads a file, it cannot read one, regardless of what a customer writes.

How often should the agent's permissions be reviewed? Review them on a fixed schedule and after any incident, such as a misdirected message or a new integration. Compare the granted permissions with the tools actually in use, sample declined requests and confirm that handoffs are being handled. Small, regular checks catch drift long before it becomes a data problem.

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