Secure Calendar CLI Unified Protection
Your organization uses Google Calendar, Outlook Calendar, or both. The Secure Calendar CLI applies one set of rules across all calendar providers, so AI agents get consistent, controlled access regardless of the platform.
How PortEden Protects You
Six layers of security between AI and your data.
Single Config for All Calendars
Write your calendar security rules once and the CLI enforces them identically on Google Calendar and Outlook Calendar.
Normalized Event Data
The CLI normalizes calendar event data from both providers into a consistent format before applying your visibility rules.
Cross-Platform Attendee Controls
Block AI agents from seeing specific attendees across both calendar providers with a single rule definition.
Calendar-Specific Access Scoping
Restrict agents to specific calendars within each provider, keeping personal, team, and HR calendars hidden.
One config schema — Google + Microsoft normalized
Google Calendar uses calendar.events.list(calendarId, timeMin, timeMax) with RFC 3339 timestamps and ISO 8601 recurrence. Microsoft Graph uses /me/calendars/{id}/calendarView with startDateTime/endDateTime query params and a totally different RRULE serialization. An agent wrapper either picks one or maintains two adapters that drift apart. The Calendar CLI ships a single normalized event schema:
{
"id": "google:c_classroom:abc123", # or "outlook:AAMkA..."
"calendar": { "id": "...", "name": "Team Standup", "provider": "google" },
"start": "2026-05-21T15:00:00-04:00", # always RFC 3339 with tz
"end": "2026-05-21T15:30:00-04:00",
"summary": "Standup",
"attendees": [], # stripped by policy
"body_text": "", # stripped by policy
"recurrence": { "rrule": "FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR" },
"free_busy": "busy"
}One policy file, both providers
# ~/.porteden/calendar.yaml — applies to all connected calendar accounts
defaults:
fields_visible: ["start", "end", "summary", "free_busy"]
strip_attendees: true
strip_body: true
time_window: { past: "1d", future: "30d" }
per_provider:
google:
calendar_allowlist: ["adam@porteden.com", "c_classroom:standup"]
use_freebusy_endpoint_when_possible: true
outlook:
calendar_allowlist: ["Calendar", "Boardroom A"]
use_delta_token: truePicking the right endpoint per provider
The CLI knows which provider supports what: use_freebusy_endpoint_when_possible routes Google calls to /freeBusy (cheaper, lower scope); use_delta_token routes Outlook calls through Graph delta tokens to avoid full re-scans. The agent sees the same shape regardless — but the network/throttling profile matches each provider's best-practice path.
Why this matters for cross-platform incident response
When an audit asks "did agent X read meeting Y", the answer needs to be a single grep — not "check the Google audit log, also check the Microsoft Compliance Center, correlate by timestamp". One log with {agent, provider, calendar_id, event_id, ts} turns a multi-hour evidence-gathering exercise into a query.
Get Started in 3 Steps
Install and Connect Calendars
Install the PortEden CLI and connect your Google Calendar and Outlook Calendar via their respective OAuth flows.
Define Calendar Policies
Create your config file with visibility rules, attendee controls, and calendar scoping that applies to both providers.
Deploy and Monitor
Route AI agents through PortEden so calendar queries to any provider are filtered through your rules with unified audit logging.
Without vs. With PortEden
Without PortEden
- Separate security configurations for Google Calendar and Outlook Calendar
- Different APIs return different event formats with different levels of detail
- Attendee visibility rules maintained separately per provider
- Calendar audit logs split between Google Workspace and Microsoft 365
With PortEden
- One config file governs calendar access across both providers
- Normalized event format ensures consistent data filtering
- Attendee rules apply identically across Google and Outlook Calendar
- Single audit log captures all calendar access from all agents