AI security · Engineering & business perspective
A practical guide to identity, least privilege, approval boundaries, and auditability when an assistant can use business tools.
Twinlink Editorial · 3 min read
01
A model that explains a policy can be wrong in a way that a reader notices. A model that changes an account or submits an order can create consequences before anyone reads its explanation. That is why an agent’s authority should be designed independently from the quality of its reasoning.
Think of the model as a proposal generator. It can suggest what should happen, but a policy boundary decides whether the proposed action is permitted for the current user, target, and context. A natural-language instruction should not silently broaden that boundary.
02
The system should distinguish the person requesting work, the service invoking a tool, and the identity used by the downstream application. Collapsing these into one powerful service account makes it difficult to reason about access and difficult to investigate an incident.
Tool calls should carry structured context: the requester, the allowed operation, the intended resource, and an expiry where appropriate. Credentials remain with the execution service. They should not be copied into prompts or exposed as ordinary conversation context.
03
Just-in-time access narrows both the duration and scope of authority. A reviewed request to update one account should not become permission to update every account. If an action changes after approval, the system should treat it as a new proposal.
Temporary credentials are useful only if the receiving system enforces their scope. A short-lived token that still grants broad administrative power leaves important risk unresolved. Authorization has to be enforced by the tool boundary, not by a model instruction to “be careful.”
04
An assistant may read a document, ticket, or webpage containing instructions that conflict with the user’s request. That content is evidence to interpret, not a new authority to follow. Tool permissions should remain stable even if the retrieved text asks for a different action.
Evaluate the workflow with adversarial documents, malformed tool arguments, expired approvals, and ambiguous targets. A security test should exercise the execution boundary, not merely inspect whether the model produces reassuring language.
05
Logs are valuable when they answer a question. Who requested this change? Which policy allowed it? What did the tool actually return? Was the operation retried? A transcript alone often cannot answer these reliably.
An operations team should be able to pause a workflow, revoke access, and inspect incomplete actions without editing the model prompt. Those controls make an agent a manageable service. They also let a business start with a narrow workflow and expand only when the evidence supports it.
Let’s build what comes next