Posts

Featured Post

Preventing Tool Exploitation: Centralizing Policy Across Repositories, APIs, and MCP Servers

Image
Preventing Tool Exploitation: Centralizing Policy Across Repositories, APIs, and MCP Servers Preventing Tool Exploitation: Centralizing Policy Across Repositories, APIs, and MCP Servers Date: 13 November 2026 Executive Summary AI systems increasingly act through tools that read repositories, call APIs, execute workflows, and access MCP servers. Each tool expands the system’s authority and creates another location where an attacker, compromised identity, malicious instruction, or policy mistake can produce unauthorized impact. The business risk is not limited to prompt injection. The larger problem is fragmented control: one service validates identity, another interprets permissions, and a third records incomplete logs. Security teams should make a deliberate architectural decision to centralize authorization policy and policy evaluation while keeping enforcement close to each tool boundary. Centralization does not mean giving one component unrestricted control. It mea...

Before an AI Agent Changes Production Data, Test the Action, Not the Intent

Image
An agent can have the right identity and still make the wrong change. That’s the production risk many teams miss. They verify who the agent is, then assume its requested action is safe. But identity answers only one question: which agent is acting? It doesn’t answer whether this action is justified, scoped correctly, or appropriate for the current context. Consider a hypothetical support agent with permission to update customer records. A ticket says: “Correct the customer’s billing region and apply the standard account update.” The agent retrieves the customer record, calls an internal update tool, and changes the billing region. The request sounds routine. But the agent has interpreted “standard account update” as permission to modify a field that affects downstream billing logic. The failure isn’t that the agent was compromised. The failure is that the control boundary trusted the agent’s interpretation. A role such as support-agent is too broad to authorize a production mut...

Latest DevOps & Cloud News – 12 November 2026

Image
๐Ÿ“ฐ Top DevOps & Cloud Articles Anthropic built a model that beats Opus. It recommends Opus anyway. Source : The New Stack Anthropic just released a coding model that beats Opus 5.5 on two major benchmarks and can complete certain difficult tasks The post Anthropic built a model that beats Opus. It recommends Opus anyway. appeared first on The New Stack . Why Nvidia gave OpenShell to the CNCF Source : The New Stack Nvidia this week donated OpenShell, its open-source runtime for securing and governing AI agents, to the Cloud Native Computing Foundation. The post Why Nvidia gave OpenShell to the CNCF appeared first on The New Stack . Expensive accelerators, no workload-level visibility: Introducing Amazon CloudWatch accelerated compute insights Source : The New Stack Accelerator bills have become one ...

The Danger of Standing Tokens: Moving to Ephemeral, Scoped Access Paths for AI Tools

Image
The Danger of Standing Tokens: Moving to Ephemeral, Scoped Access Paths for AI Tools The Danger of Standing Tokens: Moving to Ephemeral, Scoped Access Paths for AI Tools Date: 12 November 2026 Executive Summary AI tools increasingly act across source repositories, ticketing systems, cloud platforms, internal APIs, and production workflows. When these tools use long-lived API keys, shared service accounts, or broadly privileged tokens, a single prompt injection, compromised integration, or leaked secret can become a persistent path into the enterprise. The security decision is straightforward: treat every AI tool call as a high-risk, policy-controlled access request rather than as a trusted internal operation. Replace standing credentials with short-lived, narrowly scoped authorization, enforce policy at the tool boundary, and produce an audit record that connects the human request, model decision, tool invocation, identity, and result. Contents Architecture and Th...

An AI Agent Can Stay Within Its Permissions and Still Do the Wrong Thing

Image
The first authorization check is often the least important one. A user asks an agent to update a supplier record. The request is approved. The agent has permission to read the supplier system and write changes. Then the plan changes. The agent decides it needs to export related payment details, call a second system, or update several records instead of one. The original authorization may still be technically valid, but it no longer represents what the agent is about to do. That is the failure mode: authorization gets attached to the conversation, while risk changes with every new action. A hypothetical failure Imagine an internal procurement agent asked to correct a supplier's address. Its first plan is simple: Find the supplier record. Update the address. Confirm the change. The agent cannot find the supplier using the provided name. It revises the plan: Search invoices for a matching company name. Read payment records to confirm the identity. Update the supplier ...