---
title: "Smartsheet's MCP integration moves work-management permissions into agent execution"
description: "AWS connects Smartsheet's live work data to agents in Amazon Quick and Kiro. Enterprises should test delegated identity, sheet-level authorisation and confirmation for every consequential tool call."
url: "https://devencelab.com/insights/2026/10/20/smartsheets-mcp-integration-moves-work-management-permissions-into-agent"
date: "2026-10-20"
section: "Insights"
tag: "Agentic AI"
author: "Devence Lab"
reading_time: "3 min read"
site: "Devence Lab"
license: "Readable and quotable with attribution to the canonical URL."
---

# Smartsheet's MCP integration moves work-management permissions into agent execution

AWS connects Smartsheet's live work data to agents in Amazon Quick and Kiro. Enterprises should test delegated identity, sheet-level authorisation and confirmation for every consequential tool call.

AWS published a Smartsheet Model Context Protocol integration guide on 20 October 2026, demonstrating access through Amazon Quick for business users and Kiro for developers. The connection lets AI assistants work with live sheets and project information rather than static exports. That solves a practical context problem, but it also puts ordinary work-management permissions directly in the path of autonomous tool execution.

Smartsheet's earlier AWS architecture description establishes a shared remote MCP server behind an API gateway, OAuth validation and domain services. Users can read and change sheets through tools, while fine-grained permissions remain enforced by the application's own services. Standardising the tool connection does not eliminate the difference between asking about a project and changing its status.

## Identity propagation must survive every tool call

The Amazon Quick Smartsheet documentation requires users to sign in with their own Smartsheet accounts and says actions run with those users' permissions. OAuth scopes and sharing permissions are different layers: a scope may allow a class of operations while a user still lacks access to a particular sheet. Enterprises should verify both decisions for every read and write, including operations initiated from a developer's IDE.

Do not replace user delegation with a broad shared service credential merely to simplify an MCP deployment. Inspect token audience, expiry and granted scopes, then test the same request with users holding viewer, editor and administrator roles. An account that cannot edit a sheet through the application should not gain that ability through an agent.

> A connected agent should inherit a user's authorised work, not become a shortcut around the controls that protect it.

## Read and write tools need different release gates

A request to summarise overdue tasks is low risk compared with updating deadlines, adding collaborators or deleting rows. Both may arise from one natural-language conversation. Operators should publish distinct tool inventories for read-only analysis and state-changing tasks, and require confirmation for actions with material business consequences.

Apply parameter validation at execution time. Restrict permitted workspaces and sheet identifiers, reject unrecognised destinations and guard against instructions embedded inside task descriptions or attachments. A malicious comment inside a project row is untrusted data, even when it arrives through an authenticated MCP response.

## Operational checks must track committed state

Smartsheet's earlier architecture notes that agent questions may trigger multiple API calls within seconds, requiring per-user and operation-specific rate limiting rather than IP-only controls. This becomes important when an agent loops through rows, retries failed updates or fans out across several projects. Instrument the requesting identity, tool, target object, outcome and correlation ID without unnecessarily copying confidential project contents.

Start with a pilot workspace and known test users. Compare what Quick and Kiro can read and mutate, verify permission denials, and introduce idempotent updates and rollback procedures. The announcement is evidence of a supported connection pattern, not a guarantee that every enterprise's role model and audit requirements will be enforced automatically. Treat MCP onboarding as a security-control change with a documented owner and a measured acceptance test.

Produced through Devence Lab's automated research and publishing workflow, without prepublication human review. Devence Lab retains editorial responsibility. Sources are linked; report factual errors to contact@devencelab.com.

## Sources

- [Work management context for AI agents with Smartsheet MCP on AWS](https://aws.amazon.com/blogs/machine-learning/work-management-context-for-ai-agents-with-smartsheet-mcp-on-aws/) - AWS Machine Learning Blog
- [How Smartsheet built a remote MCP server on AWS](https://aws.amazon.com/blogs/machine-learning/how-smartsheet-built-a-remote-mcp-server-on-aws/) - AWS Machine Learning Blog
- [Smartsheet integration in Amazon Quick](https://docs.aws.amazon.com/quick/latest/userguide/smartsheet-integration.html) - AWS Documentation