Mcp | The AWS Blog

Autonomous Incident Operations Need Boundaries

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

An incident ticket contains one piece of the truth. Metrics live in CloudWatch, deployment history lives in a delivery system, and ownership usually lives in a CMDB. An agent that can correlate those sources can save an operator a lot of context switching.

The harder question is what happens when the agent wants to change something.

The AWS DevOps Blog’s integration between AWS DevOps Agent and ServiceNow is interesting because it puts that question in the tool layer. Through Model Context Protocol and ServiceNow’s MCP controls, teams can decide which tools are visible, which actions are authorized, and which calls are recorded.

That is the difference between autonomous investigation and an unbounded automation account.

Start with read access

Autonomous incident response should earn its write permissions. The first useful version of this integration does not need to restart instances, change security groups, or deploy code. It needs to gather evidence quickly and put a coherent explanation back in the incident.

A narrow first tool set might include:

reading an incident and its related records,
querying the CMDB for affected resources,
retrieving CloudWatch and deployment context,
adding a diagnosis or evidence summary to the incident,
creating a proposed change request without executing it.

Each tool should have an owner, a defined input and output contract, and an explicit reason it is available. The agent should not discover a broad administrative API just because the underlying integration can technically call it.

The source article describes the ServiceNow MCP Server Console as the place that governs which tools the agent can access and what actions it can perform, with invocation auditing. That is the useful control point. Governance should not depend on the model remembering a paragraph in its instructions.

The workflow should end in a human decision

A practical incident flow looks like this:

A ServiceNow incident triggers an investigation.
The agent reads the incident, queries approved AWS telemetry, and correlates recent changes.
It writes its findings and confidence level back into the record.
If mitigation is needed, it proposes a change with evidence and an expected rollback.
A human approves, rejects, or modifies the action through the normal change process.

That workflow still saves time. The operator starts with context rather than a blank ticket. It also preserves the part of ITSM that exists for a reason: a record of who approved a potentially disruptive action.

Do not call a system autonomous simply because it can click the final button. In production, the more valuable form of autonomy may be fast evidence gathering and high-quality proposals.

MCP is plumbing, not policy

MCP gives the agent a standard way to discover and call external tools. It does not make a tool safe. The safety comes from the server-side permissions and from how the tool is implemented.

For every write-capable tool, ask:

Can the tool scope the target account, service, and environment?
Is the action idempotent?
What evidence must exist before it can run?
Does it create a change record or bypass one?
Can the action be reversed, and who owns the rollback?
Is the full request and result captured for audit?

An agent that can restart a service should not automatically be able to delete a database. A tool that can create a change request should not also be able to approve it. Separate those capabilities so a prompt mistake or compromised credential cannot collapse the whole control path.

How I would measure a pilot

Start with one business service and one operations team. Use read-only AWS and ServiceNow tools for the first iteration. Measure whether the agent finds the right resource, identifies the relevant recent change, and cites the evidence without inventing a correlation.

Track investigation time, incorrect conclusions, missing records, tool errors, and every denied invocation. A useful success criterion is not just a lower mean time to resolution. It is also a complete audit trail and a predictable human handoff.

Only then add low-risk writes, such as updating the incident or opening a proposed change. Keep high-impact actions behind approval until the team has several weeks of real evidence.

Autonomous operations are not made trustworthy by enthusiasm. They become trustworthy when the agent has a small tool surface, explicit permissions, observable decisions, and a recovery path. The AWS and ServiceNow integration gives teams the pieces. The operating model is still ours to design.

Portable Agent Plugins Need Strong Contracts, Not Just a Shared Folder

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

Packaging the same agent extension for every client is wasteful. One tool expects a certain directory layout, another wants a different manifest, and a third wraps the same MCP server in its own configuration. The extension author ends up maintaining several copies of the same idea.

AWS’s announcement of support for Agent Plugins addresses that friction with an open standard for portable agent extensions. The initial scope covers Agent Skills and MCP servers in a shared plugin structure.

That is a useful start. It is not the whole portability problem.

What the standard gets right

A small standard is easier to implement and easier to govern. Agent Plugins defines a directory structure and manifest so a compatible client can discover skills and MCP server configuration without a bespoke adapter for each tool.

The source article describes extension authors doing redundant work to adapt the same components for different clients. One portable package can reduce that duplication and give clients a common vocabulary. The involvement of multiple ecosystem participants also matters: an extension standard is more useful when it is not controlled by a single product roadmap.

I like the decision to keep the first version narrow. A standard should define the minimum needed for interoperability and leave clients room to decide how they install, present, and manage extensions.

The hard parts are contracts

A directory layout does not tell a client whether a tool is safe or reliable. Before shipping a plugin, document the contracts around it.

Permissions: What files, network endpoints, APIs, and secrets does the plugin need? Can a client display those requirements before installation and enforce least privilege at runtime? An MCP server that can read an AWS credential or a local workspace needs a much clearer boundary than a static skill file.

Versioning: A plugin can be structurally valid and still be incompatible with a client or a dependent server. Define how breaking changes, minimum client versions, and deprecation windows are communicated. A version field is not a compatibility strategy by itself.

Lifecycle: What happens when an MCP server crashes, hangs, or loses authentication? The client needs a timeout, restart policy, and a useful error surface. Otherwise a portable plugin simply moves the debugging problem from packaging into runtime discovery.

Observability: Every skill and tool invocation should have structured logs and correlation IDs. When a portable extension fails in one client but works in another, the team needs to compare tool inputs, timeouts, permissions, and returned schemas.

These are the contracts that determine whether portability survives contact with production.

Test more than installation

A plugin should be tested in at least two compatible clients before anyone claims it is portable. Installation is the easy check. The interesting tests are:

a missing permission,
an unavailable MCP server,
a tool timeout,
a changed response schema,
two skills calling the same tool concurrently,
an update that must be rolled back.

For each test, record what the user sees and what telemetry the operator receives. A portable extension that fails differently in every client is not yet portable in the operational sense.

I would also keep the plugin’s domain logic outside the client-specific wrapper. Skills should document their assumptions, and MCP servers should expose stable, validated tool contracts. That makes it possible to reuse the same extension in a local developer tool and in a controlled enterprise agent runtime without copying business logic.

Where the ecosystem should go next

The first version can provide a foundation, but future iterations will need stronger answers around permissions, trust, signing, sandboxing, lifecycle, and policy evaluation. Organizations will also want an inventory of installed plugins, their versions, their owners, and the data they accessed.

Those requirements should not all be forced into the core standard immediately. They can evolve through documented conventions and interoperable metadata. What matters is that teams start treating an agent plugin like a deployable component, not like a harmless prompt file.

The practical takeaway is positive but measured: Agent Plugins can stop authors from rebuilding the same extension for every client. The next value comes from the ecosystem agreeing on the contracts around that package. Prototype a plugin in two clients, declare its permissions and dependencies, instrument its tool calls, and report what breaks. That feedback is more useful than another compatibility badge.