Welcome, everyone. Today we're focusing on MCP runtime. MCP runtime is our active real time security shield that inspects and enforces guardrails on every AI interaction to prevent unauthorized actions.00:05Here's what we're covering today. 1st, we'll explore the core capabilities of MCP runtime, specifically how we inspect, filter, and govern AI interactions to ensure our security policies are always active and effective. Following that, we'll jump into a live demo.00:22You'll see firsthand how to create policies that intercept and block unauthorized activity and how to drill down into the event logs to review those actions in detail. Let's get started. So, let's talk about the real power behind our MCP runtime capabilities.00:40We've built these to be more than just a security layer. There's a complete shift in how we handle AI to tool interactions. Here's what we're bringing to the table. Real time interception, this is our proactive shield. We're analyzing every single AI to tool requests the moment it happens. We aren't waiting for a postmortem.00:59We're stopping risks in their tracks before they ever reach their destination.01:19Automated guardrail enforcement, we've moved past manual oversight. Our system automatically triggers security, privacy, and safety guardrails. Whether it's preventing data leakage or blocking unauthorized tool access, the system handles it instantly, keeping our environment secure without slowing down the workflow.01:23Context aware filtering, this is where things get smart. The system doesn't just look at the request, it understands the intent. It filters actions based on the specific risk profile of the target tool or repository ensuring that security is always relevant to what's actually happening.01:43Instant visibility, we've prioritized total transparency. Every time an action is blocked or audited, you get an immediate actionable log. It's a crystal clear audit trail that shows exactly what our security posture looks like in real time. Policy driven control.02:01Finally, we've built in the flexibility to choose our own path. You have granular control to decide whether to block or monitor based on the sensitivity of the data. If you recall from our last video on MCP scanning.02:17We successfully registered our MCP server ARNA and took a deep dive into the audit report to get a clear picture of our environment. Now that we've analyzed those risks, it's time to take action and create a runtime policy. However, before we proceed with creating the new policy.02:33We 1st need to set up a few prerequisites that are necessary for it to function. The 1st prerequisite is to create a connection. A connection defines where AI defense should send requests by specifying the MCP server endpoint as well as how it should authenticate with the server using the required credentials.02:52Once the connection is created, it can be reused by multiple policies, eliminating the need to configure the server details and authentication every time you create a new policy. This makes policy creation simpler and ensures consistency across policies.03:10To do this, navigate to the MCP section. From here, we'll navigate to the connections tab. Once in the connections tab, we'll click add connection. There are two connection types available, gateway and API.03:27For this demo, I'm selecting gateway. I give the connection a descriptive name. Choose our honor MCP server from the list and click Create connection. And with that, the connection is created. It's now in a pending status.03:43Ready to be fully integrated. Once we associate the policy that we will shortly create to the connection, you can see the policy name displayed here as well. 2nd prerequisite for creating a policy is to create an MCP security profile. This is where we define a risk based security.04:00The profile that governs how MCP servers are protected.04:20Think of the MCP security profile as the intelligence behind your governance strategy. It acts as an automated security policy engine, allowing you to define how the system responds to different types of risks without requiring manual intervention for every MCP server.04:24To create an MCP security profile, navigate to the secure section, select MCP security profiles under profiles and click create profile. We have three settings that we need to set in this MCP security profile. Risk based access control, tool access.04:40As control and asset drift detection.05:001st, with the risk based access control, you can define threat severity. E.g., if a threat with a medium, high or critical severity, the system should automatically monitor it. This gives us the visibility we need to assess the situation before deciding if we need to block it.05:06Next, we have tool access control. This is where we get surgical. You can see all 18 tools on the ARNA MCP server listed here. We can choose to monitor or block access to each individual tool. This is critical because not all tools carry the same risk.05:27Some might be harmless while others, like those that export data needs stricter oversight. Finally, we have asset drift detection. The system is constantly watching for changes to your MCP servers, tools or prompts.05:45If anything changes, it automatically triggers a rescan ensuring your security posture is always up to date. You'll notice we have this action toggle everywhere. Whether it's for risk based access, tool control or even drift detection, you have the final say on whether to monitor or block.06:02It's this level of granular, automated control that makes me such an advocate for this product. By creating this profile, we've effectively set our rules of engagement for the AI. You notice that the number of associated policies is zero, and that's our next step is to attach that profile to the policy we are going.06:20Going to create.06:40Now, it is time to create the runtime policy. You can create the policy by either clicking on protect server with policies in the MCP server report page or you can navigate to secure section then select runtime policies under policies. This takes us directly into the add new policy workflow where we can start enforcing the control.06:43Roles that keep our data safe.07:03Now, we are ready to create the runtime policy. Runtime policies continuously enforce risk based policies to control MCP server and tool access while detecting and blocking unsafe runtime activity. As you can see, the platform guides us through a structured process from policy details and connections to go.07:05Hardware profiles and MCP profile configurations.07:25It's very intuitive. We start by giving the policy a clear name and description. This allows us to set specific guardrails for data protection and legal compliance ensuring that our AI interactions remain secure and responsible, and that's the power of Cisco's AI defense.07:29We've gone from registering a server to identifying risks, creating a profile, and now building a policy to lock it all down. I've named this policy ARNA MCP server policy demo. Next, I chose Arna MCP server connection demo connection that we previously.07:47Created. It is now linked and ready to go. The next step is defining the guardrail profiles. This is where we tell the AI exactly what it can and cannot do. You have two choices here. You can select from our pre built system profiles.08:07Or create a brand new one tailored to your specific needs. I'm going to create a new one called ARNA MCP server demo profile to show you the level of control we have. This is where the platform really shines.08:24We have three pillars of protection, security, privacy, and safety. Under security, we can block threats like prompt injection or tool exploitation. Under privacy, we can automatically redact PII, PCI or PHI.08:39And under safety, we can filter out toxic content or hate speech. What's even better is the advanced configuration. For any of these rules, we can adjust the sensitivity or specific categories. E.g., in security guardrails.08:59We can set the filter strength for prompt injection or choose exactly which URL categories to block using Cisco Talos intelligence. You can also set the URL reputation threat level. Once you've tuned your guardrails, you just hit create.09:19It's a powerful, granular way to govern your AI. You aren't just setting a policy, you're building a custom security perimeter around your AI tools. Now that we've configured our general guardrails, the next step is to choose MCP security profile.09:34The MCP security profile that we previously created is detected and ready to be used. The profile is disabled by default. Toggle on the disabled button to enable the existing profiles and I'm selecting the ARNA MCP guardrail profile right here.09:53As you can see, once you choose and enable the profile, the profiles overview is instantly populated. It shows us exactly what we are applying, our risk based access control, which is currently set to monitor for medium and high threats in our tool access control, which is covering all 18 tools on the ARNA MCPS.10:11Server. This is the beauty of this workflow. By selecting this profile, we're applying a tailored security logic that we've already vetted. It ensures that our ARNA MCP server is being governed exactly the way we intended. We've arrived at the final step.10:30The policy summary. This is our sanity check, a consolidated view of everything we've configured. You can see the policy name, the connection we're protecting, and the MCP security profile we've just enabled. It's all here. We've successfully bridged the gap between identifying a risk and enforcing a defense.10:48When I click save and enable, this policy goes live, providing real time protection for our Arna MCP server, and that's it. We've taken a complex potentially risky AI tool, scanned it, profiled it, and wrapped it in a security policy, all in just a few minutes.11:08Once we have our guardrails in place, the next crucial piece is visibility. Here in the events logs, you can see exactly how our security policies are performing in real time. As you can see on the screen, we have two block events triggered by the MCP gateway.11:28Let's take a look at a real blocked event in the event logs. At the bottom, we can see that an MCP gateway request to the ARNA MCP server was blocked based on the applied security policy. Selecting the event opens the detailed view on the right where we can see exactly why the action was blocked.11:47Under the match section, we can see that the MCP tools access policy was triggered and the configured action was blocked. The threat finding section explains the reason behind the decision. In this example, the request was identified as containing indicators of tool exploitation and tool poisoning, which violated our security policy.12:04Finally, the general section provides important audit information, including the event time stamp, event ID, and the enforcement action that was taken. This gives security teams complete visibility into why the request was blocked and provides the evidence needed for investigation and compliance.12:25This is a perfect demonstration that our configured policies are actively intercepting and stopping potential risks before they reach the environment. And there you have it. In just a few minutes, we've gone from registering an unknown server to identifying critical vulnerabilities and setting up automated guardrails to protect it.12:42It's a complete end to end security life cycle. I hope this demo showed you just how simple and powerful this defense can be. We're really setting the bar for what secure AI looks like. Thanks.13:01
