The Permission Problem: Keeping AI Agents Inside Their Authority

AI agents turn permissions into operational risk

An AI agent does not need malicious intent to become a dangerous insider. It needs only broad credentials, an ambiguous objective and enough autonomy to act faster than a human can review its decisions. A customer-support agent with access to email, refunds and account records might interpret “resolve this complaint” as permission to disclose personal data or issue an excessive payment. A coding agent authorised to deploy software could overwrite production configuration while attempting to fix a minor defect. The central security question is therefore not whether an agent is intelligent, but whether its authority is precisely bounded.

Traditional identity and access management was designed largely around people and predictable software services. Employees occupy stable roles; service accounts tend to execute narrow, repeatable processes. Agents sit awkwardly between the two. They can choose tools, form plans and generate novel sequences of actions, yet may operate through credentials created for a human administrator. Every additional integration expands the possible action space. Giving one agent access to Slack, Salesforce, GitHub, cloud infrastructure and a payment platform does not create five isolated risks; it creates combinations, such as extracting customer details from one system and transmitting them through another.

The danger is amplified by speed and scale. A person might update 20 records before noticing a flawed instruction. An agent can alter 20,000 in minutes. It can also be manipulated indirectly: a malicious instruction hidden in a document, support ticket or web page may persuade it to reveal secrets or invoke a privileged tool. Permission design must assume that models will sometimes misunderstand intent, follow hostile content or choose an unsafe path. Capability cannot be treated as trustworthiness.

Start with scoped credentials, not borrowed identities

The first control is straightforward: an agent should have its own identity and narrowly scoped credentials. Allowing it to impersonate an employee through a shared password, browser session or all-purpose API key destroys accountability and imports every privilege that person has accumulated. A finance assistant that only drafts invoices should not inherit the finance director’s ability to approve bank transfers. A repository-maintenance agent that labels issues and opens pull requests does not need permission to bypass branch protection, change secrets or delete repositories.

Scopes should describe both resources and actions. “Read customer cases in the UK support queue” is materially safer than “read all CRM data”; “create draft refunds up to £100” is safer than “manage payments”. Where a platform offers only coarse roles, organisations can place a broker or internal API between the agent and the underlying service. The broker exposes a small set of approved operations, validates their parameters and withholds the master credential. This adds engineering work and sometimes latency, but it converts an open-ended integration into a controllable interface.

Credential isolation also limits the blast radius of compromise. Separate production from testing, separate departments and, for higher-risk work, issue credentials per agent instance or task. Secrets should remain in a vault and be injected only when a permitted tool call occurs; they should never appear in prompts, model context or logs. If an agent can read a credential as text, it may reproduce that credential as text. Architecture should make secret exfiltration difficult by design rather than relying on instructions that say, “Do not disclose this key.”

Policy checks must sit outside the model

Natural-language guardrails are useful guidance, not reliable authorisation. Telling an agent to “avoid large refunds” leaves “large” undefined and asks the same probabilistic system that proposes an action to police itself. Enforceable policy belongs in deterministic code outside the model. Before any consequential tool call, a policy engine should evaluate the agent’s identity, requested action, target resource, data classification, monetary value, environment, time and relevant business state.

Consider a procurement agent attempting to create a purchase order. External checks might require an approved supplier, a valid cost centre, a price below £5,000, no split orders within 24 hours and a delivery address already registered to the company. The model may recommend the purchase and explain its reasoning, but it cannot waive those conditions. A rejected request should return a structured reason that allows the agent to choose a safer route, such as producing a draft for human review, without exposing sensitive policy internals.

Policy systems also need context and version control. A £5,000 threshold may apply to routine equipment but not to controlled chemicals; access to payroll data may be permitted from a managed workload in London but denied from an unverified runtime. Record which policy version authorised each action so investigators can reconstruct decisions months later. The tradeoff is complexity: overly rigid rules create false rejections and operational delays. Teams should measure denial rates, exception requests and policy overrides, then refine rules without quietly replacing hard limits with model judgement.

Approval gates should match consequence, not novelty

Human approval is valuable when a mistake would be costly, irreversible or difficult to detect. It is wasteful when applied to every routine action. The practical answer is tiered autonomy. An agent may read public information and draft internal text freely; it may update low-risk metadata under policy; it may need one reviewer to contact a customer or issue a modest refund; and it may require two authorised approvers to transfer funds, delete data or change production access controls.

An approval screen must show what will happen, not merely the agent’s prose summary. Reviewers need the exact recipients, amounts, files, database rows, permissions and external destinations, plus a clear diff where applicable. “Approve deployment” is inadequate if the package also modifies an identity policy. Approvals should bind to a cryptographic hash or immutable representation of the proposed action. If the agent changes the payload after approval, the gate must trigger again. Otherwise approval becomes a ceremonial click attached to a moving target.

Gates introduce delay and can encourage rubber-stamping. Queue design therefore matters. Route requests to people with domain authority, set expiry times and prioritise by risk. Sample reviews can work for low-impact, repetitive actions: for example, automatically allow address-format corrections while reviewing 5% for quality. By contrast, a request to export 50,000 customer records should never pass through sampling. Good governance reserves scarce human attention for decisions where judgement genuinely changes the risk.

Time-limited access closes the standing-privilege gap

Standing access is convenient and hazardous. An agent that reconciles accounts for two hours each Friday does not need payment-system privileges for the remaining 166 hours of the week. Just-in-time access replaces persistent authority with short-lived tokens issued for a named task. A token might permit read access to one ledger and the creation of draft adjustments for 30 minutes, then expire automatically. If the runtime is compromised later, the attacker finds fewer durable privileges to exploit.

Time limits should be paired with use limits and task binding. A credential can expire after 15 minutes, after ten API calls or immediately after the approved workflow completes. For particularly sensitive operations, authorisation should be single-use: one approved transfer, to one beneficiary, for one amount. Refresh should require renewed policy evaluation rather than an automatic extension controlled by the agent. Emergency revocation must propagate quickly across brokers, caches and downstream systems; a nominally expired token is little protection if services accept it for another hour.

Short lifetimes create operational tradeoffs. Tasks can fail mid-process, clocks can drift and frequent token issuance adds infrastructure load. Agents therefore need idempotent operations, resumable workflows and explicit recovery paths. If a token expires after a database update but before confirmation, the agent should check the transaction state rather than repeat the update. Reliability engineering and access control are inseparable: poorly designed retries can turn a safe, limited credential into duplicate payments or repeated customer messages.

Data access needs purpose and destination controls

Read permission is often treated as low risk, yet data retrieval is the first half of most disclosure incidents. An agent authorised to read contracts may summarise them into a public chat channel; one that searches support tickets may place health or payment information into a third-party model context. Controls must govern not only whether data can be accessed, but why it is accessed and where it can go. Purpose-bound access can restrict retrieval to records connected to the current case, customer or investigation.

Data-loss prevention should inspect both inputs and outputs around the agent. Sensitive fields can be masked before entering model context, with tokens restored only inside an authorised downstream operation. A support agent may need to know that a card exists and ends in 1234, but not receive the full number. Egress rules can block personal data from unapproved email domains, consumer file-sharing services or models without suitable retention terms. Network controls should prevent an agent from creating arbitrary outbound connections simply because it can generate a URL.

There is a real utility cost. Redaction can remove context needed to resolve unusual cases, and strict destination rules can obstruct legitimate collaboration. The answer is graduated access: begin with minimised data, permit targeted elevation when policy conditions are met and require approval for bulk or cross-boundary movement. Organisations should set quantitative thresholds, such as escalating exports above 500 records or any dataset containing more than two classes of regulated information. Specific limits are testable; broad promises to “handle data responsibly” are not.

Auditability turns controls into evidence

Every agent action should produce a trace that connects intent to effect. Logs need the agent identity, user or process that initiated the task, model and configuration version, tools invoked, policy decisions, approvals, credential grants, relevant inputs and the resulting system changes. Sensitive prompt content may need hashing, redaction or controlled storage, but omitting the trail entirely leaves security teams unable to distinguish model error, operator misuse and external attack.

Monitoring should focus on behavioural signals as well as single events. A refund of £80 may be permitted, but 200 such refunds in an hour are anomalous. Other useful indicators include access outside normal task windows, repeated policy denials, rapid enumeration of records, new external recipients and attempts to invoke tools unrelated to the stated objective. Rate limits and circuit breakers can pause the agent automatically when thresholds are crossed. A kill switch must disable credentials and active sessions, not merely send the model another instruction to stop.

Finally, controls must be tested against realistic failure modes. Red teams should place hostile instructions in documents, simulate compromised connectors, request boundary amounts and probe whether approvals can be reused. Teams should track measures such as privileged actions per task, percentage of actions requiring human review, mean time to revoke access and the number of policy violations prevented before execution. Keeping agents inside their authority is not a one-off permission exercise. It is an operating discipline built from scoped identity, external enforcement, temporary privilege, visible decisions and rapid containment.