Model Context Protocol · Claude · Microsoft 365 Copilot · ChatGPT

Supercharge your AI with TATER.

Connect any MCP-compatible AI assistant directly to your TATER compliance and operations data. Your AI becomes a compliance operator, ITSM teammate, audit-prep engineer, and living-documentation engine — reading your real tenant state and writing back through the same audit-logged surface your humans use. No copy-paste. No screenshots. No hallucinations from stale knowledge.

Get connected Talk to sales

Three ways to connect your AI.

TATER ships an MCP (Model Context Protocol) server with 111+ tools. Any client that speaks MCP can connect — read your compliance posture, list open tickets, draft policies, prepare audit evidence, and write back to TATER on your behalf.

Path A

Claude Desktop / claude.ai

Two-line config in claude_desktop_config.json. The bundled mcp-remote bridge proxies stdio to the TATER HTTP MCP at api.tatersecurity.com/api/mcp. Authenticate with an org-bound TATER API key.

Setup guide →
Path B

Microsoft 365 Copilot

Declarative agent + API plugin manifests. Side-load via Copilot Studio or as a Teams app. Authenticates with the user's Entra ID identity so every action runs as the actual person — full audit trail.

Setup guide →
Path C

ChatGPT & other MCP clients

HTTP MCP endpoint speaks the standard JSON-RPC protocol. Any agentic framework — OpenAI Assistants, Azure AI Foundry, Mistral, custom in-house — can use it with API key + org ID query params.

Endpoint details →
Cost model

TATER pays no AI token cost.

All inference happens in your AI session — Claude on your subscription, Copilot on your M365 license, ChatGPT on your API key. TATER's job is to expose your tenant data as MCP tools. No platform LLM bills. No per-tenant token quotas to manage. You bring your own AI; TATER becomes its operating substrate.

What it actually does for you.

Six concrete patterns where AI + TATER outperforms either alone. Each pattern is built into the MCP server's instructions and reinforced by the Three-Doc Rule and Help-Desk Session Pattern below.

Use case · Living documentation

Create documentation as a side-effect of working.

Every diagnostic, remediation, and architectural conversation your AI assistant has against your TATER tenant ends with three durable records: an Ops task (lifecycle), a Configuration Document (the org's actual state), and a TATERpedia wiki page (generic methodology). The next person who asks the same question finds the answer already written.

  • Network topology, identity model, scanning configuration — all maintained by the AI as it touches them, not as a one-time greenfield write-up
  • Provenance baked in: every AI-generated doc records the source prompt, model, and human review state
  • Validators reject docs without a summary, related-controls list, and tag taxonomy — output is consistently structured
Example prompt
"Document our SCuBA M365 conditional access posture. Cover what's enforced, what's exempt, and where the gaps are. Save it to TATERpedia."
AI calls get_org_context, list_policies, get_failing_controls, search_config_docs, then writes a structured wiki page with the actual CA policy IDs, exempt user groups, and the 3 controls currently failing — cross-linked to each. Audit log records the page as via: claude.
Use case · Faster ticket resolution

Resolve in minutes, not days.

When the help-desk gets "I can't sign in" or "our SOC2 audit needs evidence by Friday", the AI agent walks the same data the human would — but in parallel across scans, controls, change requests, audits, and the wiki. It surfaces the relevant prior incidents, identifies the root cause from current state, and proposes the fix with the exact PowerShell/Graph call.

  • Help-Desk Session Pattern enforces: search Ops tasks first → create-or-continue → append findings throughout → bulk-link entities at resolution
  • Cross-references controls, risks, change requests, and vendors in one prompt
  • Drafts the remediation script, surfaces it for human approval, then executes via trigger_remediation
Example prompt
"User alex@cb.com can't sign in from VPN. Trace it."
AI calls list_tasker_tasks (any prior open tickets? — none), creates an Ops task with the symptom verbatim, then runs get_failing_controls, get_control_grc_context, list_overrides. Finds: conditional-access policy CA-VPN-MFA updated 2 days ago by change request CR-2391 now requires authenticator-app MFA. Alex's user is on the SMS-only exemption list (expired yesterday). Updates the ticket with root cause + 3 remediation options (extend exemption, reset auth methods, or re-enroll). Logged as via: copilot.
Use case · Continuous compliance

Audit prep becomes a background process.

Your AI watches scans, manual-review controls, and risk acceptances and stays ahead of audit cycles. When evidence is missing, it gathers it; when justifications are stale, it drafts updates; when frameworks change, it identifies the deltas and proposes how to close them.

  • Evidence Library auto-populates: AI calls get_evidence_job_status and posts findings to control threads as comments
  • Risk acceptances drafted with consistent format — controlId, severity, justification, expiry, approver — using create_risk_acceptance
  • POAM items auto-created from failing controls and aging risks via auto_populate_poam
  • Framework narratives drafted via set_framework_narrative with the actual implementation status surfaced from controls
Example prompt
"Our SOC2 Type II is in 60 days. What needs evidence collected, and what's already covered?"
AI calls get_compliance_summary(framework=SOC2), get_framework_narratives, list_recent_audit_log. Returns: 47 controls covered (87%) · 4 controls missing evidence · 2 stale risk acceptances expiring in audit window. Drafts an evidence-collection task per missing control, assigned to the right owner, with the suggested commands or screenshots needed.
Use case · Change-impact analysis

Know what breaks before the change ships.

Proposed changes traditionally rely on a human change-board's intuition. AI + TATER turns that into data: query every control that touches the system, every dependent vendor, every audit finding from related changes, every policy gate. Output: a risk-scored impact analysis with rollback plan.

  • For every change request, AI calls get_control_context, list_risks, list_pending_changes to surface adjacent in-flight changes
  • Drafts the rollback plan and adds it to the change as a comment
  • Highlights downstream controls that the change would knock from Pass to Manual Review
Example prompt
"Change request CR-2412 proposes disabling legacy auth on Exchange Online. Walk the impact."
AI calls get_control_context(EXO-AUTH-001), list_pending_changes, list_risks. Returns: 14 controls move from Manual Review → Pass · 3 controls newly Fail (legacy POP3 sync, fax-to-email gateway, 2010-era scanner) · 1 active risk acceptance on legacy auth must be retired · estimated rollback time 4 minutes. Adds the analysis to the change as an audit-logged comment.
Use case · Federal ATO pipeline

Draft POAMs, RMF stages, and SSP narratives in hours, not weeks.

The federal pipeline benefits the most from AI augmentation because it's documentation-heavy. AI agents that know your actual control implementations and current scan posture can produce first-draft POAM items, RMF step descriptions, and SSP control narratives at scale — leaving humans to review, not author from scratch.

  • auto_populate_poam seeds open POAM items from failing controls + accepted risks
  • create_ssp and set_framework_narrative populate the SSP with actual implementation language from your TATERpedia
  • RMF lifecycle tracking + STIG/SCAP import + OSCAL export — see the Federal/DoD ATO pipeline
Example prompt
"Auto-populate the POAM for everything currently failing or accepted as risk. Group by severity."
AI calls get_failing_controls, list_overrides, auto_populate_poam. Creates: 17 new POAM items · 5 Critical / 8 High / 4 Medium · each scheduled to the assigned control owner · each linked to the source failing-control evidence. Returns count + IDs + flagged duplicates suppressed.
Use case · Meeting → action

Meetings produce documents, tasks, and risks — not just minutes.

Drop a meeting transcript into TATER and your AI agent extracts decisions, follow-ups, business-documentation drafts (SOPs, role definitions, vendor briefs), and risks raised. Each artifact is linked back to the source meeting for full provenance.

  • Meeting Records + transcripts (sensitivity-gated) feed any MCP-compatible AI as primary source material
  • AI drafts SOPs and process maps directly into the Business Documentation library with create_business_doc
  • Action items become real Ops tasks via create_tasker_task, attributed to the meeting attendee mentioned
Example prompt
"Process the weekly architecture review transcript I just attached. Extract decisions, draft any SOPs, file action items."
AI calls get_meeting_transcript, append_meeting_decision (x6), create_business_doc (new "On-call rotation handoff" SOP, draft), create_tasker_task (x4 — assigned to attendees by name). Updates meeting status to processed, links all created artifacts back. Notifications fire to assigned task owners.

Two rules baked into the MCP server.

When you connect an AI assistant via TATER's MCP, it inherits a strict working pattern via the server's mandatory instructions. The rules ensure documentation is the natural output of every session — not an afterthought — and that help-desk sessions don't fragment into orphaned threads.

Three-Doc Rule

Every diagnostic, troubleshooting, or remediation session produces all three of:

1. An Ops task (lifecycle: who reported, status, root cause, resolution)
2. A Configuration Document (specific org state at conclusion)
3. A TATERpedia wiki page (generic methodology)

All three cross-link. Next time the same scenario comes up, the answer is already written — the AI finds the wiki via search_wiki, the ConfigDoc via search_config_docs, and the prior incident via list_tasker_tasks.

Help-Desk Session Pattern

On any "something is broken" or "user can't…" request, AI agents must follow a 4-step pattern:

1. Search Ops firstlist_tasker_tasks by requester + symptom. Continue an existing ticket if one exists.
2. Create immediately — if no match, file create_tasker_task with the symptom verbatim.
3. Append findings throughout — every discovery is a comment, not an overwrite.
4. Bulk-link at resolution — connect the ticket to every entity touched (controls, ConfigDocs, change requests, risks, vendors).

What this replaces in your day.

Side-by-side: the manual workflow vs. the AI + TATER workflow. Time saved compounds.

Before

Quarterly compliance review

One auditor + one engineer · 2 weeks · 40 hours of evidence collection across portals, screenshots, manual spreadsheets, "where did we put that script again"

After

Same review with AI + TATER

~3 hours of human review on AI-drafted artifacts. Evidence already attached. Risk acceptances already documented. New POAM items already filed. Framework narratives already drafted.

Before

"My VPN broke" ticket

Help-desk technician spends 30 min reproducing, 30 min in Entra portal, 30 min searching Slack for "did we change this", documents nothing because it's late.

After

Same ticket with AI + TATER

15 min. AI surfaces the relevant change request that broke it (CR-2391 yesterday), proposes the fix, the technician approves. Ticket, ConfigDoc, and wiki page are written automatically.

Before

Onboarding documentation

New engineer reads stale Confluence pages, asks 8 different people on Slack, builds wrong mental model, ships first PR with a security regression.

After

Same onboarding with AI + TATER

New engineer asks the AI any question. AI calls search_wiki + search_config_docs + get_org_context, returns the actual current-state answer with provenance. No stale wiki. No Slack ping chains.

Ready to supercharge?

Connect Claude, Copilot, or any MCP-compatible AI to your TATER tenant. Setup is under 10 minutes for Claude Desktop; M365 Copilot is a side-loaded Teams app. Both authenticate against TATER's existing identity model — same role-based access, same audit log, same MCP tool policy controls that govern human users.