# AI agent permissions: give systems only the access they need https://palnau-systems.vercel.app/insights/ai-agent-permissions-least-privilege Published 2026-11-10 by Oliver Palnau and the Palnau Systems team. Prepared with AI assistance. Audience: Business owners, IT managers and security leads. Give an AI agent only the data access and actions required for its assigned workflow. Separate reading from writing, limit access to relevant records and use a dedicated identity where appropriate. Enforce these boundaries in the connected systems, not only in a prompt. Review permissions when the workflow changes and provide a fast way to disable access without disrupting unrelated business operations. ## Key takeaways - Separate tool availability from actual permission to act. - Use narrowly scoped identities and record-level access where supported. - Test denied actions and cross-customer access before launch. ## Translate the job into an access map List the business task, the records it needs and the specific operations it performs. A support assistant may need product guidance and a customer’s open tickets but no access to payroll, all customer exports or administrator settings. “CRM access” is too broad to describe this requirement. Name fields, record groups and actions whenever the system supports that granularity. Compare the proposed access with the workflow charter. If a permission is convenient but not necessary, leave it out until a concrete use case justifies it. This makes later reviews easier and reduces the consequences of a mistake or a malicious document influencing the agent. ## Choose an accountable identity Decide whether an action occurs on behalf of a specific employee or through a dedicated service identity. Preserve the initiating user and business case in the audit record. Avoid using an owner’s everyday administrator login as the default integration account; it makes the agent’s reach difficult to control and its actions harder to distinguish. In a hypothetical property management company, a maintenance triage agent can read requests for assigned properties and create internal tasks. It cannot view unrelated owner statements, change vendor banking details or approve expenses. When a manager changes property assignments, the retrieval layer applies the updated access rules. ## Enforce boundaries at the tool layer A prompt saying “never access other accounts” is not a substitute for authorization. The application should check the user, account and requested operation before returning data or performing a change. Validate identifiers and avoid accepting an account ID from an untrusted document as proof of access. For consequential actions, combine permission checks with approval rules and limits. A role may be allowed to prepare a refund without authority to issue it. Keep secrets out of model-visible text and logs. Credentials should be managed through the platform’s supported secret handling rather than pasted into agent instructions. ## Review and revoke deliberately Create a permission register with the integration owner, purpose, scope and review date. Include offboarding and incident procedures. Test how quickly the team can revoke one agent’s access and what happens to work already in progress. A process should pause clearly rather than repeatedly retrying with broken credentials. Copy-ready access review brief: “For each agent connection, identify the business purpose, identity, readable records, writable actions and approval requirements. Flag permissions unused by the workflow. Demonstrate a denied cross-account request and a successful revocation.” Treat new tools and new data sources as access changes requiring review. ## First steps 1. Map each workflow to required records, fields and actions. 2. Choose an identity with a named owner and limited scope. 3. Enforce authorization outside the model at every data and action boundary. 4. Test cross-account, denied-action and expired-credential cases. 5. Document permission reviews and a rapid revocation procedure. ## What to measure Unnecessary permission count: Review granted permissions against observed and documented workflow needs. Authorization test coverage: Track which protected operations and record boundaries have explicit allow and deny tests. Revocation time: Measure the time from a disable request to confirmed inability to read or act through the connection. ## Is read-only access safe enough? Read-only access prevents changes through that connection, but it can still expose confidential information. Limit which records can be read and where outputs can be sent. Access scope and data handling matter even when the agent cannot edit a system. ## Can one agent share an administrator account? That may be technically possible but is often a poor operating choice. Ask whether a dedicated scoped identity or delegated user access can meet the need. The goal is to separate authority, trace actions and revoke access without affecting unrelated work. ## Sources and further reading - [NIST: Least privilege](https://csrc.nist.gov/glossary/term/least_privilege) - [Model Context Protocol: Security best practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) ## Work directly with Oliver and his team Work directly with Oliver and his team to design agent access around real tasks, accountable identities and practical controls. Free introductory call: https://calendly.com/oliverpalnau/30min Services and scope: https://palnau-systems.vercel.app/services Current pricing: https://palnau-systems.vercel.app/pricing