AI agents just got APIs. They got identity. And they're starting to plug into the automation tools teams already use to change real systems. So the question is moving past, can AI write code? The better question is, what happens when AI can open pull requests, call tools, authenticate to services, and trigger operations workflows? Because at that point, you did not build a chatbot. You built a coworker with API access. I'm Brian Teller from Teller's Tech, and this is Ship It Weekly. Welcome back to Ship It Weekly, The show where we look at DevOps, SRE, cloud, platform, and security stories that actually matter when you're the person who eventually has to keep the thing running. This week, we're looking at GitHub making copilot cloud agent tasks available through a REST API. Auth0 bringing authentication to MCP servers. Red Hat positioning Ansible as an execution layer for agentic IT operations. and OpenAI Daybreak, pushing AI deeper into security research and remediation. Then we'll step away from the AI cycle for a really good Discord engineering story on automating ScyllaDB operations at scale. And in the lightning round, we'll hit AWS GuardDuty and CryptoMining Detection, queues and backpressure, and why an index scan can still ruin your day. The theme this week is authority, not intelligence, not productivity, authority. What can these agents reach? What can they change? Who approved the action? And when something breaks, who owns it? That's the thread for this episode. So let's get into it. First up, GitHub Copilot Cloud Agent Tasks can now be started through the REST API. This is the right place to start because it sounds like a small product update, but it changes the shape of the thing. GitHub says copilot business and enterprise users can now programmatically start copilot cloud agent tasks through a new agent tasks REST API. Currently in public preview, the copilot cloud agent works in the background in its own development environment. It can make code changes, validate those changes, and open a pull request. That part alone is already interesting, but the API is the bigger shift, because now this is not just a developer manually asking copilot to work on something from inside GitHub. Now another system can kick it off. That means you could wire this into custom workflows, a support escalation, a bug triage process, a security finding, a dependency update workflow, a backlog grooming process, or whatever else somebody decides to connect. And that's where this gets operationally interesting. Because once an agent can be started by automation, it becomes part of your automation surface. It becomes something you need to reason about like any other system that can create change. What repos can it touch? What permissions does the token need? Who approved the task? What branch protection applies? Can it create a pull request but not merge one? Can it trigger CI? Can that CI deploy? And if the workflow is kicked off by another tool, do you still have a clear human owner? That last one matters, because it is very easy to imagine a chain like this. A vulnerability scanner opens a ticket. A workflow kicks off an AI agent. The AI agent makes a patch. CI passes. A PR gets opened. Somebody rubber stamps it because the diff looks boring and the scanner says the vulnerability is resolved. And maybe that is great. Maybe you just saved an engineer three hours. Or maybe you just created a subtle production issue from a change nobody really understood. The practical takeaway here is not don't use it. The practical takeaway is that agent workflows need the same boring controls we already expect from normal engineering workflows. Branch protection, required reviews, code owners, scope credentials, audit trails, clear ownership, and a very bright line between agent can propose and agent can ship. The interesting part of AI agents is not that they can do work. The interesting part is that we have to decide how much authority that work gets. That leads nicely into the second story. Auth0 announced that auth for MCP is generally available. MCP, or Model Context Protocol, has become one of those terms that shows up everywhere now. It is basically a way for agents and AI tools to connect to external systems, tools, APIs, and data sources in a more standardized way. And that matters because agents are only as useful as the tools they can reach. A model sitting in a chat box can give advice. A model connected to tools can take action. And once it can take action, authentication and authorization stop being side concerns. They become the whole game Auth0 announcement is focused on putting an identity layer around MCP servers They call out authentication CIMD registration and on behalf of token exchange The plain English version is this If agents are going to call tools those tools need to know who or what is calling them on whose behalf, and what that caller is actually allowed to do. That sounds obvious, but a lot of early agent tooling has been built in a way that feels like local developer convenience first, production safety second. You spin up a server. You connect it to your agent. You give it access to some tools, and suddenly your agent can read things, write things, query things, maybe even change things. That's fine in a sandbox. It is not fine when the tools are attached to customer data, production infrastructure, internal admin APIs, CICD, billing systems, or cloud accounts. And this is where identity gets weird, because with a normal user, we mostly know how to think about it. Brian logged in. Brian clicked a thing. Brian had these permissions. With an agent, the story is messier. Was the action taken by the agent? By the user who asked the agent? By the application hosting the agent? By a service account? By a delegated token? And when something goes wrong, where does accountability land? That's why I think this Auth0 story is more important than it looks. MCP is not just a cute connector system for demos. It is becoming connective tissue for AI tooling. And connective tissue needs identity, authority, logging, and revocation. Otherwise, we're just building a faster way for something to call the wrong API with too much permission. For DevOps and platform teams, this is probably where the real work starts. Not how do we let every team use agents, but how do we let teams use agents without turning every MCP server into an ungoverned production backdoor? Before we get to the next story, a quick note from this week's sponsor, GuardSquare. If you are building mobile apps, good enough security is usually a problem waiting to happen. GuardSquare focuses on actually protecting your code in addition to scanning it. That means code hardening, runtime protection, testing, and visibility into what's happening once your app is out in the wild. So if you are responsible for shipping and securing mobile apps, Android or iOS, definitely worth taking a look at GuardSquare.com. All right, back to the show. Third story, Red Hat is pushing Ansible Automation Platform as a trusted execution layer for IT operations in the agentic era. That is a very enterprise sentence. But underneath the marketing language, this is actually a big deal. Because Ansible is not theoretical. Ansible is already used to patch systems, restart services, configure servers, manage network gear, run operational tasks, and handle a bunch of work that is very close to production reality. So when you connect AI agents to Ansible, you are not just giving an agent a little toy function. You are connecting it to the machinery that already changes real systems. Red Hat's angle is basically this. Agents may be good at reasoning, planning, or interpreting intent. But enterprises still need a governed, trusted, auditable execution layer when it is time to actually do something. That is the right framing. Because the dangerous version of agentic operations is not an agent saying, here's the runbook. The dangerous version is the agent saying, I ran the runbook. And then everyone hoping it did the right thing. Now, to be fair, this is also where something like Ansible can help. Because mature automation gives you structure. You have inventories. You have playbooks. You have item potency, at least when things are written well. You have logs. You have a known execution path. You have a place to put approval gates. That is much better than an agent freehanding shell commands on a production box because it read three confluence pages and felt confident. But the same rules apply here. The agent should not get more authority than the automation deserves. deserves. If your existing playbooks are messy, overly broad, poorly scoped, or rely on tribal knowledge, an agent does not magically make them safe. It may just make them easier to invoke. And that is the part I'd be nervous about. A bad script that an agent can discover and execute through a tool interface is a different class of problem. So the takeaway is not Ansible plus AI is bad. It is actually the opposite. If agentic ops is coming, I'd much rather see agents routed through controlled automation than improvised commands. But teams should treat this as a forcing function. Clean up your automation. Narrow the blast radius. Split read-only diagnostics from mutating actions. Make destructive playbooks require approval. Add dry run modes where possible. Make sure the logs clearly say who asked for the action, what agent or system executed it, and what changed. Because if Ansible becomes the execution layer for agents, the quality of your automation becomes the quality of your agent safety model. Fourth story, OpenAI announced Daybreak, its cybersecurity initiative built around GPT 5.5 and Codex security. I'm treating this as a follow-up to the Mythos and Project Glasswing episode, not a totally separate story. Because the broader trend is the same. AI systems are getting better at vulnerability discovery exploit reasoning patch generation and remediation validation OpenAI describes Daybreak as a way to use AI for cyber defense The pitch is that it can help identify threats generate patches and verify remediation across code and systems. And on one hand, this is exactly what we want. Most organizations are drowning in vulnerability backlog. They have more findings than time. Some findings are noisy, some are real. Some are technically real, but not actually reachable. Some are buried in legacy code that nobody wants to touch. And even when the fix is obvious, there is still work. Open the issue. Find the owner. Understand the code path. Patch it. Test it. Get it reviewed. Deploy it. Verify the scanner is happy and hope nothing broke. So an AI system that can help triage, validate, patch, and verify is genuinely useful. But here's the uncomfortable part. If defenders get this, attackers get some version of it too. Maybe not the same controlled access, maybe not the same polished product. But the underlying capability trend is not one-sided. That means the bottleneck for security teams shifts. It is no longer just can we find vulnerabilities. It becomes can we process, prioritize, patch, and safely ship fixes fast enough. And that lands right in the lap of DevOps, SRE, platform, and application teams. Because finding the bug is only step one. The real work is changing the system. And changing the system safely requires all the boring stuff. Ownership, tests, CICD, feature flags, rollback plans, dependency strategy, runtime visibility, asset inventory, patch windows, and enough architectural knowledge to know when the easy fix is actually a trap. This is why I keep coming back to the same point. AI security tooling will probably find more issues. That is good. It will probably also create more pressure. That is complicated. If your organization already struggles to patch known vulnerabilities, adding AI that finds more of them does not automatically make you safer. It may just make the backlog more honest. So the real question is not can Daybreak find things. The question is, can your engineering system absorb the findings? Can you validate them? Can you prioritize them? Can you patch them? Can you ship them? Can you prove the fix worked? And can you do all of that without creating a second incident while fixing the first one? That is where this becomes a operations story, not just a security story. now let's step away from ai for a minute because discord published a really good write-up on how they automate sila db clusters at scale and honestly this is the kind of engineering story that i love discord's persistence infrastructure team runs a lot of sila db over time they had accumulated python and shell scripts to help with operations but those scripts had the usual problems. They were useful. They were also fragile. They were easy to misuse. They relied on humans understanding the right order of operations. And for complex cluster-wide workflows, that becomes a lot of operational risk. So they built what they call the Scylla control plane. The goal was to safely automate and orchestrate cluster-wide workflows. Things like rolling restarts, replacing nodes, bootstrapping, and doing work that previously required a lot more manual supervision. One of the details that I liked from the write-up is that webhook notifications mattered more than they expected. That sounds small, but it is very real. There is also a huge difference between babysitting a terminal for two hours and trusting the system to notify you when it needs attention. That's the difference between automation that technically works and automation that actually reduces human load. And that distinction matters. A lot of teams say they have automation, but what they really have is the pilot scripts. A script can be automation, but it might not be safe automation. Safe automation needs state. It needs preconditions. It needs retries. It needs item potency. It needs clear failure modes. It needs visibility. It needs a way to resume without making things worse. And it needs to know when to stop. That last one is underrated. Good automation is not automation that blindly completes the task no matter what. good automation is automation that knows when the world no longer matches its assumptions. If a node is unhealthy, stop. If the cluster is already degraded, stop. If replication is not where it should be, stop. If the previous step did not converge, stop. That is how you move from script that usually works to operational control plane. And this connects back to the AI stories in a weird way. Because before we let agents run operational tasks, we need more automation that looks like this. Explicit. Recoverable. Observable. Constrained. Designed around failure. If the future is agents calling tools, then the tools need to be boring, safe, and well-structured. Discord's story is a reminder that the best automation is not magic. It is just a lot of careful engineering around the parts where humans usually get tired, distracted, or inconsistent. Now let's do a quick lightning round. First, AWS GuardDuty and Crypto Mining. AWS published a guide on detecting and preventing crypto mining in AWS environments using GuardDuty. This is one of those classic cloud security problems where security reliability and cost all run into each other A compromised credential does not always turn into a dramatic data breach Sometimes it turns into a compute bill Someone gets access they spin up resources they run mining workloads, they try to persist. And by the time anyone notices, the incident is both a security problem and a finance problem. The practical question for teams is simple. If somebody compromised a credential today and started mining in your AWS account, how fast would you know? Would it be guard duty? Would it be cost anomaly detection? Would it be Datadog? Would it be a budget alert? Would it be a developer asking why their workload is slow? Or would it be finance two weeks from now, forwarding a bill and asking what happened? That is the difference between having a detection strategy and having a surprise. Next, queues and backpressure. There was a good piece making the point that queues do not absorb load faster. They delay failure. And that is exactly right. Queues are great for smoothing bursts. They are terrible when teams use them to hide sustained overload. If messages are arriving faster than consumers can process them, the backlog will grow. A bigger queue does not fix that. It just gives you a bigger place to store the problem. Eventually, you hit freshness issues, storage limits, memory pressure, retry storms, customer-facing delay, or some downstream dependency that finally gives up. So the practical takeaway is simple. Monitor queue depth. monitor message age, monitor consumer lag, have back pressure, have limits, know when to shed load, and please, do not call a system resilient just because it has a queue in front of the fire. Last lightning item. Datadog had a nice Postgres SQL performance write-up about inefficient index scans. The short version is that using an index does not automatically mean a query is cheap. Datadog walked through a production query where the plan used an index scan, but it was still expensive. They changed the indexing strategy and cut average latency from 300 milliseconds to 38 microseconds. That is a ridiculous improvement. And it is a good reminder. You cannot stop at the query uses an index. You need to understand whether it is using the right index, how many rows it is touching, how selective the predicate is, what the access pattern looks like, and whether the index actually matches the way the query behaves in production. Sometimes the database is not slow. Sometimes your mental model is. The human closer this week is about authority, because that is really what all these agent stories come down to. Not intelligence, not productivity, not whether the model is impressive. authority. What is this thing allowed to do? What can it read? What can it change? Can it trigger work? Can it authenticate? Can it call tools? Can it run automation? Can it open pull requests? Can it touch production? And maybe the hardest question, who owns what happens next? Because in real operations, ownership is not optional. If I write a Terraform change and it breaks something, I own that. If I approve a bad pull request, I own that. If I run the playbook against the wrong environment, I own that. AI does not remove that responsibility. It just makes the path to action shorter. And shorter paths to action are great when the guardrails are good. They are terrifying when the guardrails are vibes. That is where I think a lot of teams are going to struggle. They're going to treat agent adoption like a tooling rollout. Enable the feature, give access, write a quick policy, maybe do a lunch and learn. And then six months later, they will realize that they created a new automation layer that nobody fully owns. That is not a reason to panic. It is a reason to be deliberate. Start small. Keep agents in proposal mode before execution mode. Treat MCP servers like production APIs. Treat agent tokens like service accounts. Treat agent created pull requests like code written by a junior engineer who is fast, confident, and occasionally very wrong. And before an agent can run a workflow, make sure the workflow itself is worth trusting. Because the future probably is not humans versus agents. It is humans deciding which agents get authority, where the boundaries are, and what systems are safe enough to let them touch. That is engineering work. And honestly, it is probably some of the most important engineering work we are going to do over the next few years. That's it for this week of Ship It Weekly. We covered GitHub Copilot Cloud Agent tasks through the REST API. Auth0 bringing identity to MCPC servers. Red Hat connecting Ansible to agentic IT operations. OpenAI Daybreak and the next phase of AI-assisted security. Discord Scylla DB automation work and a lightning round on Guard Duty crypto mining detection, queues, and database indexes. If you found this useful, follow the show. Share it with someone who is either excited or mildly terrified by agentic operations. And check out the weekly brief at OnCallBrief.com. I'm Brian Teller from Teller's Tech. Thanks for listening. And remember, if your AI agent can open a pull request, call an MCP server, authenticate through your identity provider, and trigger Ansible, congratulations. You did not build a chatbot. You built a coworker with API access. Maybe give it a badge, but maybe don't give it production admin on day one. Outro Music
