AI Security
AI Agents Need Their Own Security Boundaries
An agent that can act across business systems needs an owner, a defined identity, limited permissions and a reliable way to review and revoke access.
7 min read — Altitude IT Support
An AI assistant that drafts a reply is different from an agent that can read business files, send messages, update records or trigger workflows. When software can take actions across systems, access control needs to describe the agent as well as the person who asked it to work. A shared administrator login or an employee's unrestricted account makes it difficult to know what the agent was allowed to do and how to stop it.
What Google announced—and what that does not mean
On 8 October 2026, Google Cloud announced its Gemini agent and described persistent “coworker agents” with dedicated identities, including a Workspace account, email address, calendar, Drive and company-directory presence. That is Google's product announcement. It does not establish that every Google Workspace customer already has the feature, that it is available on every plan or that an AI agent should receive broad access by default. Confirm eligibility, configuration and controls with the provider before relying on a feature.
Nor is an email address by itself a security boundary. An account may authenticate an agent, but permissions, delegated authority, connected applications, data access and the actions it can perform must still be controlled. Microsoft's documentation similarly describes dedicated agent identity and least-privilege access as security design concerns. See Google Cloud's announcement, Microsoft's guidance on authorisation for Microsoft Entra Agent ID and the NCSC's guidance on agentic AI.
Give each agent a purpose, owner and identity
Before connecting an agent, write down what business task it performs, which person or team owns it, which data it may use, what actions it can take and who approves material changes. Use a distinct managed identity for each agent or well-defined role where the platform supports it. Avoid credentials shared with a human or reused by several agents: those patterns make access attribution and revocation harder.
For Microsoft 365, map the agent to the relevant Entra identity, app permissions, delegated access or other integration mechanism. In Google Workspace, document the account or service identity, data scopes and application connections. Product-specific implementations differ, so ask the supplier how the identity is created, what audit records it produces and how administrators can disable it.
Start with the smallest useful permissions
Grant only the data and actions required for the task. An agent that summarises approved documents may need read access to a specific library, not tenant-wide access. An agent that drafts customer email can create drafts for review rather than send messages automatically. Separate read, draft, approve and execute capabilities where practical. Avoid broad directory roles and standing administrator rights.
Use human approval for actions with meaningful consequences, such as external communication, payments, account changes, bulk deletion or changes to security configuration. Approval should show the person what the agent intends to do and the target data or recipients. A generic “approve” button that hides context provides weak oversight.
Prompt injection is also relevant: untrusted text in an email, document or web page may try to steer an agent into disclosing data or taking an unintended action. Treat content as input, not authority. Limit tools, validate destinations and require confirmation before sensitive or irreversible steps. These safeguards reduce exposure; they cannot guarantee that a model will behave correctly in every situation.
Make actions visible and reversible
Record the agent identity, human requester, tools used, data accessed, actions taken, approvals and outcome, subject to privacy and retention requirements. Logs should be available to the people responsible for reviewing them and should not expose more personal or confidential information than necessary. Alert on unusual activity such as unexpected bulk downloads, permission changes or new external connections.
Test a complete task in a safe environment before connecting live business data. Include a normal request, an ambiguous request, malicious instructions embedded in a document and an attempt to access something outside scope. Confirm what the agent can do, what it refuses, what is logged and how a human can pause it. A successful demo is not a security assessment.
Manage the full identity lifecycle
Agents need the same lifecycle attention as other identities, with extra care because ownership can be unclear. Keep an inventory of agents, their purpose, owner, platform, permissions, connected data and review date. Re-check access when the task changes, a system is connected, a supplier changes or the owner leaves. Remove unused agents, revoke tokens and credentials, and confirm connected applications no longer retain access.
Decide how emergency access is stopped and who is authorised to use that process. Practise revocation: disable the agent, remove its permissions and verify that active sessions or integrations cannot continue acting. Where an agent can create sub-agents or delegate work, include those identities and inherit no more permission than needed.
Keep experimentation proportionate
Begin with a low-risk task, limited data and a human reviewer. Set an explicit success measure, a time limit and a review point. If the agent cannot explain its access or produce useful activity records, do not expand its role until the gap is resolved. The NCSC advises organisations to start carefully and apply established security controls to agentic systems; this is more useful than treating AI as either inherently safe or inherently unusable.
Altitude AI explores practical AI opportunities and governance; visit Altitude AI. For the IT side, we can help map identity, permissions, connected services and operational controls in the agreed environment. No agent deployment or particular product capability is assumed.