AI Harness EngineeringChapter 8 of 19

Part 3 — Tools, Actions, and MCP

08

Harness MCP Server and Platform Integration

Sections in this chapter

  1. 1Why a platform-native MCP server matters
  2. 2What the Harness MCP Server exposes
  3. 3Accessing Harness resources through an agent
  4. 4The authorization model
  5. 5Audit trails for MCP-driven operations
  6. 6Designing governed agent workflows on top of Harness
  7. 7Extending the Harness MCP Server
  8. 8A worked example: natural-language pipeline creation, end to end

Key Takeaways

Insight

The interview takeaway: pipeline-native (or platform-native) MCP servers sidestep an entire category of AI governance concerns by reusing the platform's existing governance. "We didn't have to re-inv

Insight

The extension story is often under-discussed in interviews. Candidates who describe only the out-of-the-box capabilities miss the question the interviewer is actually asking: "how do you plan for the

Common Trap

Any MCP server that exposes raw secret values as tool or resource output has a CVE waiting to be filed. Exfiltration via indirect prompt injection is a matter of when, not if. The only safe design is

Interview Questions

1

Walk through how an agent creates a Harness pipeline via the MCP server, end to end.

▲

Frame: the eight steps of the walkthrough in 8.3 or the worked example in 8.8 — Skill selection, context assembly, dry-run tool call, preview, approval, apply, audit. Emphasise that every step reuses existing Harness governance.

2

How do you prevent an agent from accessing secrets it shouldn't see through MCP?

▲

Frame: secrets are not exposed as values through the MCP surface at all. Agents reference secrets by name; values resolve at pipeline execution time, outside the agent's context. RBAC distinguishes secret:list (names) from value access (not in the surface). This design is deliberate and non-negotiable.

3

Design the authorization model for a multi-tenant MCP server.

▲

Frame: user-identity-as-principal (never a service account), short-lived tokens scoped to per-run agent scope, RBAC mapped to MCP tool classes, every request authenticated per-tenant, no shared service credentials crossing tenant boundaries. Audit joins agent actions with human actions in the platform's ex

4

What does a pipeline-native MCP server buy you that a standalone MCP server doesn't?

▲

Frame: inheritance of existing governance — RBAC, audit, change control, rollback — without reinvention. Security reviews approve faster because the platform is already compliant. Operations don't need parallel tooling for agent-driven changes; they show up in the same audit as human ones.

5

How would you extend the Harness MCP Server with a custom tool for your team?

▲

Frame: define the tool, route through the existing MCP surface so it inherits RBAC/audit/rate limits, author the Skill that uses it, write the eval suite, gate on eval in CI, add to approval policy if destructive. Extension is a deliberate, reviewed, versioned process, not an ad-hoc bypass.

6

Your security team says no AI agent can touch production. Make the case for the MCP-based design.

▲

Frame: the agent acts only with the invoking user's permissions; every action runs through the platform's existing RBAC and audit; destructive actions require approval; secrets are not exposed; dry-run is the default for writes; the audit trail joins human and agent actions in one place; rollback works the