MCP Operational Playbook

Connect. Assess. Understand what your AI can actually do.

Use HAIEC from your AI assistant to inspect agents, run real assurance, and follow only the evidence steps your goal needs — for your own organization or an authorized client engagement.

This playbook is the operational companion to the HAIEC MCP connection guide. It covers the five working areas — start, MCP runbook, CLI/API, agent actions, and consulting & controls — with 25 selectable operations. Conditional activities appear only when a source or decision requires them; human approvals apply only where they matter. Read-only preflight never requires a policy exercise.

HAIEC / FIELD OPERATIONS

User + consultant edition · User-led, evidence-bound

Step A · once per MCP client

Connect HAIEC MCP

Sign in, choose your HAIEC organization and create an API key for the intended job. Configure the remote MCP server in ChatGPT-compatible or other MCP client settings.

MCP server · Streamable HTTP

https://www.haiec.com/api/mcp

Authorization: Bearer <HAIEC_API_KEY>

Store the key privately in the MCP client’s secret settings. HAIEC uses API-key bearer authentication, not OAuth for its own MCP. A viewer key can inspect but not run scans.

Create an authorized key ↗ · Connection instructions ↗

Step B · first prompt

Ask HAIEC what is ready

No manual setup form needed. The assistant should call haiec_preflight, identify the caller’s organization, available systems, scopes and one recommended next action.

Copy this prompt

Check my HAIEC setup. List the AI systems I can access and tell me the one next step needed to run an assessment.

Your goal decides the evidence path: verified code, approved runtime endpoint, telemetry, or governance evidence.

Choose your goal

Start with what you want to establish

Analyze source code

Run verified remote static assurance for code capability, action paths and source findings.

GitHub App + source consent

Test live behavior

Plan a bounded, explicitly authorized runtime test. This is not continuous monitoring.

Endpoint + safety preflight

Inspect operation and authority

Use qualified policies, provider/IAM evidence, traces, logs, and supported connectors.

Only the sources needed

Pre-work, not an MCP step

Who can run this?

For your organization: use an authorized HAIEC org and a key scoped to your intended activity. For consulting: the client grants access to their HAIEC org and the specific private sources or endpoints. Record the permitted target and test conditions before consequential execution.

HAIEC’s existing identity, membership, source consent and runtime safety gates must still be honored. Do not force an independent policy-document exercise just to run read-only preflight.

Operational prompts · one at a time

Start with the core path. Conditional activities appear when the source or decision requires them; optional steps enrich evidence or add runtime operations. An asterisk (*) denotes a tool that can perform a consequential write and requires appropriate permission and confirmation.

#	Operation / use case	Prompt for your assistant	MCP owner and what runs	Status / copy
01	Check connection First use / any organization	Check my HAIEC access and show the next eligible action.	`haiec_preflight` Validates tenant, key scopes, AI systems and missing prerequisites.	Core
02	Select AI system Returning user / new engagement	List my AI systems and select the one I want to assess.	`haiec_list_systems · haiec_create_ai_system*` Use existing system; only create with explicit approval.	Core
03	Discover actions Inventory of agent capabilities	Show known agents, tools, actions, targets and which claims are source-backed or unknown.	`haiec_get_agent_trace · action map` Separates candidate, code-capable and observed facts.	Core
04	Check sources Avoid unnecessary integrations	Show existing verified evidence sources and the fastest eligible path to a meaningful assessment.	`haiec_list_sources · haiec_list_connectors` One eligible next action; no universal setup wizard.	Core
05	Connect GitHub Full remote code/source scan	Help me select and verify my authorized GitHub repository and branch.	`haiec_github_preflight → haiec_list_github_repositories → haiec_bind_github_source* → haiec_verify_source` GitHub App installation/consent remains a human/browser action.	Conditional
06	Use local / CI evidence Private CI, limited local source path	Can I submit a qualified local or CI scan instead of connecting GitHub?	`haiec_submit_local_scan*` A scan bundle is evidence, not an Assurance Evaluation; local CLI is preview.	Optional
07	Check policies Authority comparison and delegated actions	Show capability declarations and the current operating envelope; explain any missing policy evidence.	`haiec_get_capability_declaration · haiec_get_operating_envelope` Draft if missing; only human governance can approve.	Conditional
08	Run static assurance Source-code findings and consequence paths	Run source-backed assurance using my verified repository and report which engines execute.	`haiec_run_assurance*` Canonical orchestrator: source preflight → static scan → qualified evaluation.	Core
09	Follow orchestration Know what actually ran	Follow my run to completion and tell me which engines ran, skipped or failed.	`haiec_get_run` Run ID → persisted Evaluation ID; no fabricated execution.	Core
10	Understand the findings Management + technical assessment	Explain the findings, Action & Authority map, DAI and gaps from the exact evaluation.	`haiec_get_summary · haiec_get_agent_audit · haiec_get_dai_report · haiec_get_master_report` Qualified evidence and explicit NOT_ASSESSED/REVIEW.	Core
11	Prioritize evidence gaps Resolve without repeated scanning	Group open verification items and identify what human or connected system must supply.	`haiec_get_agent_audit (resolutionGroups)` Repeated static scans cannot establish absent IAM or runtime evidence.	Core
12	Add IAM facts Effective grants, roles, credentials	Identify the IAM permissions export or connected provider evidence needed for this agent.	`Approved provider/ IAM evidence → typed intake*` IAM context may remain partial; no automatic EFFECTIVELY_GRANTED claim.	Optional
13	Enable telemetry Observed actions, drift and source health	Check runtime signal readiness, and show how to connect qualified telemetry.	`haiec_get_telemetry_status → haiec_setup_telemetry*` Configure binder, instrument real producer, confirm receipt.	Optional
14	Plan runtime test Prompt injection/tool misuse testing	Run a safety preflight against this exact authorized test endpoint. Do not execute yet.	`haiec_runtime_preflight` Executable vs HELD categories shown before approval.	Optional
15	Execute runtime test Authorized behavioral proof	Run only the endpoint/categories I now expressly authorize, and report observed results.	`haiec_run_runtime_test* → haiec_get_runtime_test` Separate test service, explicit authorization; no blind retry.	Optional
16	Attach runtime results Update assurance with a completed test	Attach the completed same-system runtime test to a new assurance evaluation.	`haiec_run_assurance (attachRuntimeTestId)*` Historic evaluation never changes retroactively.	Conditional
17	Upload evidence Provider exports, logs, approval history	Preview this evidence batch, choose the qualified binder and ask before sending it.	`haiec_list_evidence_binders · haiec_ingest_structured* · haiec_ingest_logs*` Received evidence needs qualification and a new evaluation.	Optional
18	Remediation review Reduce established risk	Group findings by consequence family, show evidence and suggested action owner.	`Agent Audit · controls reads · Master Report` Recommendations are not approvals or enforced controls.	Core
19	Authorize decisions Deployment/policy change	Prepare a decision brief for the responsible human and open the authenticated approval step.	`Operating envelope DRAFT · dashboard human workflow` MCP key cannot impersonate a named human approver.	Conditional
20	Check enforcement Protect high-impact actions	Check whether a real gateway, approval gate or kill switch is installed and independently tested.	`Target-side integration / readback` Not wired ≠ protected.	Optional
21	Monitor changes Investigate anomalies, incidents and drift	Show fresh action signals, new tools, changed grants and relevant scenario evidence.	`haiec_get_telemetry_status · haiec_prepare_scenario · haiec_get_scenario_status` Anomaly is a trigger for investigation, not proof of violation.	Optional
22	Re-evaluate After new evidence or policy	Run a new evaluation with the selected evidence, then compare the exact completed snapshots.	`haiec_run_assurance* · haiec_list_evaluations · haiec_get_consequence_delta` Qualify change/comparability first.	Conditional
23	Deliver reports Executive, auditor and customer	Generate the bounded executive summary, Agent Audit and Master Report with limitations.	`haiec_get_master_report · haiec_get_agent_audit` Frozen evidence basis, coverage and disposition.	Core
24	Share proof Independent reviewer / procurement	Show available private receipts and ask before publishing or sharing any protected package.	`haiec_get_package · haiec_issue_assurance_package* · haiec_publish_package*` NO_RECEIPT is honest; publishing requires separate approval.	Optional
25	Operational handover Ongoing internal / external consultancy	Summarize risk owners, open proof gaps, connection health, follow-up and credential cleanup.	`Read report / policy / sources / receipts` Human accepts residual risk and operational responsibility.	Core

CLI & REST alternatives

HAIEC’s supported complete remote source-assurance workflow is via MCP or REST API v1. A universal fully released HAIEC local CLI is not available: local/CI analysis remains preview/enterprise POC, and GitHub Action v2 is not released.

Authenticate and inspect verified source

export HAIEC_BASE_URL="https://www.haiec.com"
export HAIEC_API_KEY="$(your-secret-manager-read-command)"
export HAIEC_AI_SYSTEM_ID="<actual-system-id>"
export HAIEC_SOURCE_ASSET_ID="<verified-source-asset-id>"

curl -fsS -H "Authorization: Bearer $HAIEC_API_KEY" "$HAIEC_BASE_URL/api/v1/systems"
curl -fsS -H "Authorization: Bearer $HAIEC_API_KEY" "$HAIEC_BASE_URL/api/v1/systems/$HAIEC_AI_SYSTEM_ID/evaluation-sources"

Run actual static source assurance (orchestrated)

RUN_KEY="$(uuidgen)"
curl -fsS -X POST "$HAIEC_BASE_URL/api/v1/assurance/runs" \
  -H "Authorization: Bearer $HAIEC_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $RUN_KEY" \
  -d '{"aiSystemId":"'"$HAIEC_AI_SYSTEM_ID"'","engines":{"static":{"enabled":true,"executionMode":"api","sourceAssetId":"'"$HAIEC_SOURCE_ASSET_ID"'"}}}'

Poll and read exact evaluation

# Use runId/evaluationId from the API responses
curl -fsS -H "Authorization: Bearer $HAIEC_API_KEY" "$HAIEC_BASE_URL/api/v1/assurance/runs/<runId>"
curl -fsS -H "Authorization: Bearer $HAIEC_API_KEY" "$HAIEC_BASE_URL/api/v1/assurance/evaluations/<evaluationId>/summary"
curl -fsS -H "Authorization: Bearer $HAIEC_API_KEY" "$HAIEC_BASE_URL/api/v1/assurance/evaluations/<evaluationId>/agent-audit"
curl -fsS -H "Authorization: Bearer $HAIEC_API_KEY" "$HAIEC_BASE_URL/api/v1/assurance/evaluations/<evaluationId>/master-report"

Independent local developer checks: npx -y ai-appsec (Semgrep installed separately) and npx -y mcp-tenant-isolation mcp for MCP repos. Neither automatically creates a HAIEC Assurance Evaluation.

Verified REST contract ↗

Action & authority assurance

Inventory broadly. Investigate consequentially.

Do not create one giant report for every greeting, menu, FAQ or configuration field. Show the full discovered action inventory, group related actions by consequence family, and produce detailed evidence cases for consequential actions, unexpected changes, and material exceptions.

Interface & source inventoryCandidate action identityConsequence familyHuman-approved boundaryFive evidence planesObserved effects & drift

Action family	Illustrative actions	Possible consequence	Recommended treatment
Content & business config	Greeting, hours, FAQs, menu, services	Customer misinformation, fraud redirection, service disruption	Family policy + specific high-impact parameter check
Knowledge & prompts	Website content, document source, system prompts	Instruction manipulation, answer poisoning, prompt injection	Inspect source, writer identity, review/approval and rollback
Communication & routing	Escalations, workflows, calls, messages, transfers	Wrong recipient, unauthorized customer contact	Tool/resource/scope-based authorization + runtime evidence
Customer data	Read/export leads, call metadata, transcripts	PII exposure, excessive reads, cross-tenant access	Data class + volume + principal + tenant monitoring
Privilege and financial effects	Role, grants, provisioning, billing, payments if available	Privilege expansion, financial loss	Strongest explicit policy/approval and target-side enforcement

Completeness rule: exposed MCP tools are not necessarily every internal capability; recognized source operations are not necessarily reachable; observed traces are not necessarily complete. Every percentage needs a source-bounded denominator.

Who decides what is consequential?

HAIEC proposes a risk-sensitive classification from qualified action semantics, effects and evidence. The accountable customer approves the operating boundary, data classes, thresholds and exceptional actions. Unknown or generic tool mappings require review, never silent approval.

What to show in the report

Executive: system/family coverage and high-risk cases. Action detail: requested, authorized, effectively granted, code-capable, observed, source/evaluation basis and proof gaps. Appendix: all recognized actions and unknown coverage.

Organization operator

Already owns the system and can select the relevant HAIEC org. Start with preflight and reuse existing assets before connecting anything new.

Opening prompt

Check my HAIEC setup and show the best way to assess the agents in my organization.

Policy creation, IAM and telemetry are offered when a claim requires them. Not prerequisites to a first static code scan.

Independent consultant

The client invites you to the authorized HAIEC organization and separately authorizes protected source access and endpoint tests. Your own consultant account cannot simply assert customer ownership.

Opening prompt

Using the organization I am authorized to assess, show its registered systems, my read/run permissions, and available evidence connections.

Keep a short engagement authorization outside the prompts: client, owner, exact system/env, intended test mode, evidence sensitivity, approval contacts.

What actually orchestrates

Static source assurance

Verified repo+branch+consent → source analyzer → qualified source/capability evidence → deterministic Assurance → frozen evaluation.

Active runtime test

Runtime preflight → explicit authorization → separate test executor → completed result → attach to a new evaluation.

Passive telemetry

Approved binder config → customer instruments emitter → accepted, qualified events → new evaluation if needed. Configuration alone is not monitoring proof.

Human approvals only where they matter

Access to a private source, source binding, evidence upload, active runtime tests, consequential configuration writes, approval of operating policy, deployment decisions, target-side control enforcement, package publication. Read-only inventory/preflight should not require unnecessary repeated approvals.

Truth boundaries: DRAFT ≠ APPROVED · CODE_CAPABLE ≠ OBSERVED · IAM simulation ≠ effective grant · TRACE ≠ target effect · CONNECTED ≠ EVALUATED · CONFIGURED ≠ ENFORCED · REPORT ≠ CERTIFICATION.