Secure Agent and Tools: How to Harden AI Tool Access

What Secure Agent and Tools Actually Means

An AI agent on its own is a model that turns prompts into text. An AI agent with tools is software that can read your inbox, write to a Drive folder, modify a Jira ticket, send email from your domain, and chain those actions together autonomously. Securing an agent is meaningless without securing what the agent can do, see, and change. That is the tools layer.

The Tool Surface in 2026

Two patterns dominate the tool surface today, and most production deployments combine them:

• Model Context Protocol (MCP) servers are the headline pattern. Claude Desktop, ChatGPT (via custom connectors), Cursor, and the growing list of MCP-compatible clients all reach external data through MCP. Each server exposes a typed set of tools (search, get, send, modify) that the model can invoke directly.
• Command-line tools (CLIs) are the second big surface. Terminal-driven coding agents, headless automation, cron-driven scripts, and CI pipelines all reach email, calendar, and drive through CLIs. CLIs also sit underneath some agent frameworks like OpenClaw, where community skills are usually thin wrappers around a CLI binary.

A typical setup mixes both. A developer might run Claude Desktop against an MCP server for inbox triage, drive a terminal coding agent through a CLI for repo work, and chain both into an automation that updates a Jira ticket. Three agents, three tool entrypoints, the same underlying tokens. That is the surface that has to be hardened.

Why Tools Are the New Attack Surface

Every tool call is an instruction the model decided to execute, often based on input that came from outside your organization. The model itself is not the threat. The threat is the combination of:

• Untrusted input arriving through email bodies, document content, calendar invites, and webhook payloads
• Powerful tools with broad OAuth scopes like gmail.full, Mail.ReadWrite, and full-Drive access
• Autonomy from agent loops that decide on their own when to call a tool, how, and how many times
• No detection because tool calls look like legitimate API traffic to your provider

Anthropic's own research found that Claude lacks contextual awareness to distinguish untrusted input from actions requiring explicit authorization, and data from low-risk connectors can flow into high-privilege executors without safeguards. This is not a Claude-specific limitation. It is the state of the art.

Real Incidents from Insecure Tool Access

The four incidents below are documented and verifiable. They are deliberately drawn from different platforms (Gemini, Claude, OpenClaw) because the failure modes generalize: any agent that holds a tool token is exposed to the same four classes of risk, regardless of which client or framework it runs in.

Failure Mode 1: Context Compaction (The Inbox Deletion)

Summer Yue, Director of Alignment at Meta Superintelligence Labs, connected an agent to her Gmail account. The agent began deleting every message older than one week. Root cause was context compaction: the agent ran out of working memory, condensed prior messages, and lost Yue's original instruction to confirm before acting. Over 200 emails were deleted before she could pull the plug. This failure mode applies equally to Claude with an MCP server, ChatGPT with a connector, or any CLI-driven agent running a long session. The mitigation is the same in all cases: a draft-only or read-only action limit on the email tool, enforced by the surface, not the prompt.

Failure Mode 2: Indirect Prompt Injection (GeminiJack)

Researchers at Noma Labs disclosed GeminiJack: a zero-click exfiltration in Gemini Enterprise. An attacker planted hidden prompt-injection commands in a shared Google Doc. When any employee performed a normal Gemini search, the RAG system retrieved the poisoned content, which then drove Gemini to search across all connected Workspace data and exfiltrate results via an embedded image tag. Zero clicks, zero warnings, zero DLP alerts. Indirect prompt injection works the same way against Claude or ChatGPT MCP tools when they read attacker-controlled content (email bodies, shared docs, calendar invites). A folder allow list plus a contact block list on outbound domains neutralizes the exfiltration path regardless of the AI client.

Failure Mode 3: Token Theft (ClawJacked)

CVE-2026-25253 let a malicious website steal an agent gateway's auth token, granting full control to the attacker. The vulnerable Control UI trusted a gatewayURL query parameter and established a WebSocket including the stored token without origin verification. The flaw compromised an estimated 40,000 systems. Token theft is a universal risk: any client that stores an MCP bearer token, an OAuth refresh token, or a CLI credential is one bug away from the same outcome. Without instant revocation at the policy layer, organizations pay for the gap in days of manual token rotation.

Failure Mode 4: Supply Chain (Malicious Tool Packages)

Researchers found over 824 malicious skills in one popular agent skill marketplace, roughly 20% of the ecosystem, distributed under a campaign called ClawHavoc. The packages disguised info-stealers as Workspace integrations and productivity utilities, deploying the Atomic macOS Stealer and other malware. The same supply-chain risk applies to any third-party MCP server, npm-installed CLI tool, or community-published skill. The lesson is unambiguous: a tool published by an unverified third party is not a security boundary. Either run trusted first-party tools, or wrap any third-party tool behind a policy layer that enforces the limits.

The Six Controls Every Secure Agent Needs

Securing the agent-plus-tools surface comes down to six controls. PortEden implements every one of them, set once and enforced on every tool call across email, calendar, drive, and tasks.

Visibility — How Much Can the Agent See

Coarse OAuth scopes return everything. A secure agent surface returns only what the policy allows. Visibility controls answer the question per resource: "Calendar: free/busy only. Drive: filenames only. Tasks: titles only." The agent never sees the underlying content unless you raise the visibility level for that resource and that user.

Contact Rules — Whose Data Is Visible

Even within a permitted resource, not every contact should be equal. Contact rules let you set visibility per email address, per domain, or per distribution list: "Block all meetings with @competitor.com", or hide every message from outside counsel, or strip body content from HR mail while keeping headers visible. Contact rules apply uniformly across email, calendar, and tasks.

Action Limits — What the Agent Can Do

The single most underused control. Read-only mode strips send, modify, and delete tools from the surface entirely. Draft-only mode lets the agent compose, but messages land in Drafts for human review. Send restrictions cap which domains can receive AI-sent mail. "Read: yes. Delete: absolutely not." Action limits are the difference between an assistant and an outage.

Time Window — How Far Back and Forward

Most useful agent work involves the last few days, not the last several years. Capping the time window to "only this week and next" shrinks the blast radius dramatically. A poisoned prompt cannot reach data outside the window, and an exfiltration attempt cannot extract decades of archived correspondence.

Account Scope — Which Accounts and Workspaces

Users routinely have multiple Workspace and Microsoft 365 accounts: personal, corporate, side project, client tenant. Account scope controls limit the agent to specific accounts or workspaces: "Only my work calendar and the Engineering board." The agent cannot leak across the boundary even if a user is signed in to all of them.

Data Reduction — What Gets Blacked Out from Responses

The last layer is field-level redaction. Even when the agent is allowed to see a message, fields can be replaced with markers: "Meeting with ***** at ***** about *****." The agent gets enough structure to summarize and triage, without the sensitive specifics ever leaving your tenant. Data reduction is also a context-cost win: redacted responses are smaller and cheaper.

Allow Lists and Block Lists Across Tools

Allow lists and block lists are how the six controls translate into per-sender, per-domain, per-folder, and per-board policy. PortEden treats them as visibility levels keyed by identifier, not as binary allow/deny switches. The same model works across email, calendar, drive, and tasks tools.

Four Visibility Levels per Sender or Domain

Each entry on a list is configured independently with one of four levels:

• Full content — the agent sees everything, including body and attachments
• Headers and metadata only — the agent sees sender, recipient, subject, date, and labels; body is stripped
• Field-level redaction — body is returned with names, amounts, dates, or other configured fields replaced by [REDACTED] markers
• Hidden — the resource is suppressed entirely; it does not appear in search, get, or thread tools, and cannot be a reply or forward target

The same four-level model maps across tool types:

• Calendar: full event, free/busy only, redacted attendee list, or hidden
• Drive: full file, filename only, redacted content, or hidden
• Tasks: full ticket, title only, redacted comments, or hidden

Patterns That Work

Common production patterns that blend allow and block lists:

• Default-deny inbox: default visibility set to hidden, with an explicit allow list of trusted customer and vendor domains at full content
• Privileged content protection: outside counsel, HR, and finance domains pinned to hidden regardless of any other rule
• Deal-window redaction: M&A contacts switched to field-level redaction during live negotiations, with deal codenames and figures masked
• Folder allow list: a dedicated AI folder in Outlook or Gmail is the only visible scope, and everything outside it is invisible
• Send-to allow list: outbound mail restricted to your own corporate domain, so the agent cannot email arbitrary external recipients
• Board-level scoping for tasks: Jira boards tagged HR and Finance set to title-only, while Engineering and Marketing boards stay at full content

Org-Wide Policies and Policy Groups

Per-token rules are useful for individuals. They do not scale to a 200-person company where every employee creates their own MCP token for Claude or ChatGPT. PortEden ships two governance primitives for this layer.

Account Policy: The Permission Ceiling

Account Policy defines the maximum permission boundary for the entire organization. No individual token can exceed these limits, regardless of who created it. Typical Account Policy rules:

• Block @competitor.com across all tokens
• Disable email send actions org-wide
• Cap calendar visibility at free/busy
• Restrict drive to a list of approved folders
• Ban specific terminated-employee accounts as resources

Policy Groups: Different Rules per Team

Policy Groups let you assign different baselines to different teams while inheriting the Account Policy ceiling. Each group can tighten further but never loosen:

• Sales: CRM boards only, read-write
• Engineering: all task boards, full access
• Marketing: drive folders + calendar, no email
• Legal: read-only across the board, no AI write actions

Identity Sync with Entra ID and Google Workspace

Policy Groups are only useful if they map to your real org chart. PortEden syncs users and groups from Microsoft Entra ID and Google Workspace, so adding someone to the Engineering group in your IdP automatically applies the Engineering Policy Group in PortEden. When someone leaves, their tokens are revoked the same way.

Audit Trails and Instant Revocation

Every tool call is logged: which client made the request, which tool was invoked, which arguments, what was returned, and what was blocked or redacted. This is the layer that answers "what did our AI agents access last quarter?" for GDPR, HIPAA, and SOC 2 reporting. Claude Cowork does not appear in enterprise Audit Logs or Compliance APIs by default. PortEden fills the gap.

Instant revocation matters as much as logging. If a Claude Desktop machine is lost, a ChatGPT connector is suspected of misuse, or a CVE drops against a popular agent gateway, one click in the PortEden dashboard cuts off the affected tokens across every connected provider while leaving healthy clients operational under their existing rules. No hunting through OAuth settings in Google Admin, Azure AD, or individual AI platform dashboards.

The PortEden Model: A Data Firewall for AI Tools

PortEden sits between any AI agent and the providers it touches. Every request is filtered through the same rules engine, regardless of which AI client is asking and which tool shape the agent is using.

MCP Servers for Claude, ChatGPT, and Cursor

PortEden's flagship surface is a set of hosted MCP servers covering email, calendar, drive, docs, sheets, and tasks. Supported clients include Claude Desktop (OAuth, recommended), ChatGPT (OAuth via custom connector for Plus, Pro, Team, and Enterprise), and Cursor and other MCP-compatible clients (manual bearer token).

Each server exposes the same tool shape across providers, so the agent calls email_search identically against Gmail or Microsoft 365 and tasks_list_items identically against Jira, Linear, Asana, Monday, or Notion. Step-by-step setup guides: connect Claude Desktop, connect Claude on the web, and connect ChatGPT. Pre-built workflow prompts (daily briefing, prepare for meeting, weekly review) ship as slash commands inside your AI client.

The PortEden CLI for Terminal and Headless Agents

For terminal-driven workflows, the PortEden CLI wraps the same security layer for scripts, cron jobs, CI pipelines, and headless coding agents. Every CLI invocation travels through the same rules engine and writes to the same audit log as the MCP servers. There is no second policy surface to keep in sync.

The CLI is also how PortEden plugs into agent frameworks that consume command-line tools. The OpenClaw integration is exactly this: install the PortEden CLI, drop the PortEden skills into the OpenClaw skills folder, and the skills call the CLI under the hood. OpenClaw users automatically inherit the full PortEden policy layer without adopting a second product. The same pattern works for any agent framework that can invoke a CLI binary.

Context Hygiene as a Security Property

Raw provider responses are bloated with MIME headers, encoding metadata, and nested structures. This is not just a cost issue. Bloated context accelerates context compaction, and compaction is what dropped Summer Yue's "confirm before acting" instruction during the inbox deletion incident. PortEden returns clean, structured data that reduces token consumption by roughly 80%, so agents hold onto their safety instructions longer and produce better results at lower cost.

Getting Started

Setting up PortEden for a secure agent and tools deployment takes about five minutes regardless of which AI provider you use. The path depends on your starting point:

1. Sign in at my.porteden.com and connect your Google Workspace and Microsoft 365 accounts through the PortEden dashboard.
2. For Claude Desktop, ChatGPT, and Cursor users: add the relevant PortEden MCP server endpoint to your client config. Setup guides for Claude and ChatGPT walk through the OAuth flow.
3. For terminal and headless agents: install the PortEden CLI for scripts, cron jobs, CI pipelines, and coding agents. OpenClaw and other CLI-consuming frameworks pick up the same security layer through the documented integration.
4. For custom integrations: connect through the PortEden API for any AI platform that does not yet speak MCP.
5. Configure access rules: set the default visibility level, add per-domain overrides, choose action limits, set the time window, and decide on account scope.
6. For organizations: define the Account Policy ceiling and create Policy Groups for each team.

The Bottom Line

A secure agent and tools deployment is not a single product decision. It is six controls (visibility, contact rules, action limits, time window, account scope, data reduction), applied consistently through allow lists and block lists, governed by an org-wide policy ceiling, logged for compliance, and revocable in one click.

That is what PortEden provides. MCP servers for Claude, ChatGPT, and Cursor; a CLI for terminal and headless agents (which OpenClaw and other frameworks consume directly); one policy layer behind all of them. Every tool call filtered, redacted, or blocked according to the rules you set once.

Your agents. Your tools. Your rules.