Extend agent capabilities with MCP servers for external tool access, then enforce safety with hooks and validation scripts that run at key lifecycle points — keeping your AI workflows powerful and trustworthy.
Transcript13 entries
Instructor:Lesson six turns the syntax into runtime leverage. Use MCP servers to extend what agents can do, and hooks to enforce what they must do. Capability and enforcement are two separate layers. If you want the practical part first, use the YouTube chapter link to jump ahead. But what I would recommend in this core lesson is this: MCP gives the assistant more tools. Hooks run before or after the tool calls and can block unsafe behavior. One extends, the other enforces. As of early 2026, we have around eight types of hooks. They're specific to session, user prompt, tool use, compaction, and subagent events. If you run the example yourself, which you can, just in a couple of minutes in Visual Studio Code, the link is available in the description below. You can check out the GitHub repo and run it on your local machine.
Instructor:Don't just watch whether the process works. Watch the behavior. Which parts are optional, which are enforced. That's the first way to internalize this difference between the prompt, tool, and guardrail. And this is one of the very important points if someone is serious about enterprise AI-assisted coding. Before we get into this workflow, let's go into VS Code and find out for ourselves. So we are in Visual Studio Code, and let's run very quickly the demo first. Now while the demo is running, I have already run the previous code. And that will produce all of this output. Right now the output is basically deleted because we have reset the source. So let's walk through the hooks. What we've got, we've got a file-protection hook, we've got a post-save hook, we've got a pre-commit hook. And I'm actually using Python files. But instead of Python, you can also use any command that runs.
Instructor:Doesn't matter. Node.js, whichever you're familiar with and you like. And I have written very simple hooks in Python, which I can run there. I also gave instructions for what is needed and also created two new MCPs. One is an NPX one using SQLite. The SQLite one, because now it is in the SQLite database, will allow the GitHub agent to access what our SQLite database looks like, such as application state or preferences, and also correlate with the metadata. The other one is a filesystem. Here the filesystem is very simple. The filesystem allows access outside of your workspace folder. I'm not actually using it for that purpose. It's just for demonstration purposes, but there are use cases. If you do not have certain
Instructor:files living in your workspace and on your local machine, and you want to go into some remote or extended folders, it will allow you to go and get some access. Very useful. It excludes any node_modules and config secrets, which we have configured anyway, but we did not allow them to write. Now I think the code is about to complete. We can see something has been generated here. So I'm pretty sure it will finish very quickly. Now coming back to this particular example, I got the verification from a previous one, and it's very interesting what happened. So we got all these use cases, and we tried, for example, denying the environment file. The agent really denied it. However,
Instructor:here's the mistake: because the agent can access the command prompt, which means it can actually echo into the env file, the operating system never enforces that. So it is about the model's guarding and model safeguarding, and models are not always updating the safeguarding processes. So that's why this second layer is enforced. This section will help your system protect your environment file and other secret files. You can also manage secrets, your cryptographic files. If there are non-standard extensions and others, you can certainly add them here and improve it. Beyond that point, file protection worked. We saw that, and we validated whether allow and deny both work fine. It can work perfectly fine. Very simple things. We just need to make sure how we are denying, defining, and citing the policies.
Instructor:What this will help with: it will also help us query the context with better safeguarding, so the model can itself safeguard. Beyond that point, it doesn't have to come to hooks every time. This will explain the behavior of our prompt and our context. Is it well safeguarded? Is it well protected? And if not, then obviously we can modify it. While we still have the hooks and other things to enforce it. Input validation, hook tests, and more. Honestly, I will say go through it. There is a lot to see here. And we have tried our best to apply many permutations and combinations. But let me tell you honestly. No one can apply all the permutations and combinations or all use cases of MCP and hooks.
Instructor:There are hundreds of them. Let me give you a very simple one. I use, in my real-life project, MCP so before it fires the test tool, I have a hook which resets the database. And after the test completes, it also resets the database. Then the tests in something like Python and other tools can actually run filtered tests or profile-level tests. And based on profile and filtered tests, we can actually send the correct database file or correct SQLite files. That helps to develop more advanced and multi-dimensional, multi-faceted testing strategies. These are the basic use cases of it. But if you run into more advanced needs, you can actually explore far deeper and more meaningful use cases of these enforcement capabilities. Not just for safety and security, but also to combine deterministic and non-deterministic workflow elements. Because the agents are non-deterministic, while the hooks and MCP are deterministic as well.
Instructor:They work wonderfully together when they are put in a proper workflow that deserves the right output. Now, I don't think that there is much to show here. The best thing is you check this out from GitHub. The link is available in the description, and then try to run it. And I would also suggest: try to write more hooks, try to write more constraints. This is very important to internalize. It's a very important capability that everyone should know. Now let's go back to our presentation and walk it through. So we are back on our presentation. Let's see what happened. Say one of the three global queries that returned zero is instead treated as a dead end, and the agent feels that signal. It thinks it needs a different strategy, and this is what we did. We enforce it to now go via the MCP.
Instructor:So it opens up other aspects, like any files. Now security has completely been bypassed because it is now looking for the allowed paths, and this is exactly what happened. In one of my personal experiences, I lost something to git rm, which is a very, very unique command to use. It means it's the last thing that the tech and the team actually use when they cannot remove the Git conflicts. But the models do not safeguard against that. They actually use it, and I lost a couple of files because of that. Since then, I have made sure that no matter what, no matter how small the project is, I always put the tech safeguarding in place beforehand and also enforce that every automation should run only
Instructor:on an isolated or sandbox environment. In this case, the agent assistant then reads the existing hook file, validation script, and MCP configuration before adding anything. Now it is accessing through the MCP, so it is full access, but still the enforcement system is in place, which ensures that any file in that set cannot be accessed. Then run the hook file, the validator script, that blocks barrel imports when they are not allowed, so safety becomes part of the code, not just an assumption of the model. The final part: we pull the unnecessary complexity from the helper logic, even enforcement code should stay minimal, understandable, and easy to maintain, and there is a reason why. The more enforcement you add, the more it will suppress the model's capability, which means the model finds it harder and harder, the model struggles and
Instructor:becomes harder and harder to explore and discover new content, which means the model will eventually perform worse. So the best part of security is not to over-engineer or under-engineer. The reason security professionals are being paid is to identify the next level of security that we need. So always make sure you start from the baseline. The common mistake is to say perfect from day one. The better approach: go incremental, put a baseline and then keep incrementing, identifying the gaps within your system and fixing them. That's the best way to find a balanced approach. One more thing, hooks can be agent-scoped, and it is a very good idea that certain hooks you develop for different types of agents, and you can actually hook them
Instructor:in the frontmatter, which ensures that only a limited number of the agents can access some special hooks that you develop, and it does not overreach or reduce the capability of your agents. The create-hook command, the forward slash create-hook command, can also scaffold a new hook for you. It's the best way to actually create a new hook, in my opinion. The Copilot CLI now supports hooks as well. So always make sure that whenever you design your workflow, it works with both modes: Copilot CLI on the command line, as well as the Copilot chat mode, which is inside Visual Studio Code. Next lesson seven, we'll cover surface strategy, the portability matrix, and building the reasoning and context layer. It's one of the very important and interesting lessons, in my opinion. It will provide you further abstraction and further abstract thinking into this process.
Instructor:Here is my challenge for you: what's the sneaky mistake that an AI tool made in your project? That you didn't catch. How did you discover it? What did you add to prevent it? Now, I already said what happened to me. I lost some code, and then I ensured that I had hooks and I also ensured that I would always sandbox. Share your worst story in the comments, and the best responses I invite to our exclusive live sessions. You would be surprised at how many different incidents have been discussed and shared in these sessions. It will be immensely beneficial. Hit subscribe and enable notifications so you get it as soon as we release the next lesson to your timeline. Thanks for watching, and I'll see you in lesson seven.
Learning Objectives4
- Distinguish between capability extensions and enforcement mechanisms in AI-assisted workflows
- Explain when to use MCP servers versus hooks for a given requirement
- Describe how validation and guardrails reduce operational risk in AI-assisted work
- Design a tooling layer that expands capability without sacrificing safety
Q&A
Q & A
Q
When should I use MCP instead of a hook?
Use MCP when the assistant needs a new capability such as browser automation, API access, or database inspection. Use hooks when you need deterministic enforcement or automation around actions the assistant already performs.
Q
Why are hooks better for protected paths than instructions?
Because hooks can block the action outright. Instructions are guidance. Hooks are enforcement.
Q
What is the practical rollout strategy here?
Add external capabilities incrementally, and add guardrails where failure would be costly. Do not collect tools without a workflow.