That second question is what an agentic security review is for.

The gap a static registry leaves open

A registry is a list someone maintains. Someone has to decide what goes on it, and that decision usually happens once, at onboarding time. The problem is that an MCP server’s behaviour isn’t fixed at onboarding. It can change with an update, expose a tool it didn’t before, or request a data scope nobody reviewed the second time around. A registry checks membership. It doesn’t check behaviour.

The obvious fix is a manual review before every server (or update) goes on the list. It doesn’t scale. Review capacity stays flat while the number of servers and updates keeps growing, and a slow review queue is indistinguishable from a “no” to an engineer trying to ship this sprint. Slow the queue down enough and people stop asking, which brings back the exact shadow-tooling problem the registry was meant to solve.

Putting the review in CI instead

We run the security review as a CI step, in the same pipeline that already runs tests and static analysis, triggered whenever an MCP server is added or updated. An agent checks the server’s declared scopes against what it actually requests at runtime, looks at outbound network calls, and confirms the tool surface it exposes matches what it claims to expose. A failing review blocks the merge.

That timing matters more than the checks themselves. Putting the review in CI means it fires at the point a real decision gets made, a merge to a branch that will actually run, rather than at a hypothetical “can I use this” moment that may or may not turn into real usage. An engineer can pull a server down and try it locally without waiting on anyone. The review only has an opinion once there’s something worth reviewing.

What this costs

Nothing here is free. Someone can spend an afternoon on a server that fails review a day later, which is a worse experience than knowing up front. We accepted that trade deliberately. Wasted local experimentation is a smaller cost than either unreviewed tooling sitting in production or a review queue so slow that people route around it.

Where this sits in the wider conversation

Security and governance around agentic tooling dominated the conversation at RSAC 2026 and the MCP Dev Summit this year, and most of that conversation comes from platform teams at large tech companies or from security vendors. Less of it comes from engineering leaders at mid-size, regulated companies who built a governance layer because they needed one operating day to day, not because it’s the product. That’s the gap this post and the last one are trying to close from our side of the fence.

If you’ve built something similar, or hit different failure modes putting a review gate in front of MCP adoption, I’d like to hear about it.

As organizations adopt AI-powered development tools like GitHub Copilot, maintaining security and governance becomes increasingly critical. The Model Context Protocol (MCP) enables Copilot to connect with external tools and data sources, but without proper controls, this connectivity can pose security risks. An MCP Registry provides enterprises with centralized control over which MCP servers and APIs their developers can access, ensuring that sensitive data and systems remain protected while still leveraging AI capabilities.

By implementing an MCP Registry, organizations can:

• Control access: Restrict Copilot to only approved, vetted MCP servers
• Maintain compliance: Ensure all AI-enhanced development activities align with security policies
• Monitor usage: Track which APIs and tools are being accessed through Copilot
• Protect sensitive data: Prevent accidental exposure of proprietary APIs or internal systems

In this guide, we’ll walk through setting up an MCP Registry using Azure API Center and configuring GitHub Copilot to use it, giving your organization the security controls needed for safe AI-assisted development.

Part 1: Set Up an MCP Registry with Azure API Center

First, we’ll follow the steps outlined in the official Microsoft documentation to create an MCP-compatible API registry. This involves using Azure API Center, which can serve as a fully-featured MCP server.

Prerequisites

• An Azure subscription with contributor-level access or higher. If you don’t have one, you can create a free account which includes $200 in credits for 30 days.
• Permissions to create resources in your Azure subscription, specifically the ability to create Azure API Center instances in your chosen resource group.
• Basic familiarity with the Azure Portal and navigating Azure resource management interfaces.
• (Optional) Azure CLI installed for automation or scripting purposes. You can install it following the official guide.

Estimated time to complete: 15-20 minutes

Steps

1. Create an Azure API Center:

   • Navigate to the Azure portal and search for “API Center”.
   • Click “Create” and fill in the required details for your new API Center instance.

2. Register MCP Servers:

   • Once your API Center is deployed, you can start registering your existing MCP-compliant servers.

3. Enable API Center Portal:

   • Under the “API Center Portal” > “Settings” section, enable the portal. This will not only allow you to manage and view your registered MCP servers through a user-friendly interface, but also ensure that the MCP endpoint is properly configured and accessible.
   • In the Visibility section, check the option “Allow “anonymous” access”, otherwise GitHub Copilot won’t be able to access the MCP registry.

4. Expose the MCP Endpoint:

   • Azure API Center automatically provides an MCP-compatible endpoint. You can find this endpoint URL in the API Center’s overview page in the Azure portal. It will look something like this: https://<your-api-center-name>.data.<location>.azure-apicenter.ms/workspaces/default.

By the end of this part, you will have a functional MCP server URL ready to be used by clients like GitHub Copilot.

Part 2: Register the MCP Registry in GitHub Copilot

Now that you have your MCP server, you need to configure GitHub Copilot to use it. This is done by defining MCP Server access in your GitHub organization or enterprise settings, as detailed in the GitHub documentation.

Prerequisites

Before configuring GitHub Copilot, verify you have:

• Organization owner or enterprise administrator role in your GitHub organization. If you’re unsure of your role, check your organization’s “People” settings.
• GitHub Copilot Business or Enterprise subscription active for your organization. GitHub Copilot Individual subscriptions do not support MCP registry configuration.
• The MCP endpoint URL from Part 1 (format: https://<your-api-center-name>.data.<location>.azure-apicenter.ms/workspaces/default).
• Access to your GitHub organization settings, specifically the “Copilot” section under organization settings.

Note: Changes to MCP server policies may take up to 15 minutes to propagate to all users in your organization.

Estimated time to complete: 5-10 minutes

Steps

1. MCP servers policy:

   • Setup MCP servers policy to Enabled

2. MCP Registry URL: The MCP Registry URL is an optional field.

   • You can enter the MCP endpoint URL you obtained from your Azure API Center in Part 1.

3. Restrict MCP access to registry servers:

   • Set this to Registry only to ensure that Copilot only accesses the APIs you have registered.

Conclusion

You’ve now successfully set up an MCP Registry using Azure API Center and integrated it with GitHub Copilot. Your developers can now leverage your organization’s API definitions directly in their coding environment.

Next Steps

• Register additional APIs in your API Center
• Create documentation for your team on using the MCP-enhanced Copilot
• Set up monitoring and analytics for API discovery usage
• Explore advanced MCP features like custom tools and prompts

Additional Resources

• Azure API Center Documentation
• Model Context Protocol Specification
• GitHub Copilot MCP Integration

Have you ever failed in a technical interview? I bet 100% of the readers will say yes unless you never did one. This article is not to teach you to succeed in a technical interview but to explain why they exist and how interviewers evaluate candidates.

Disclaimer: All information here is based on my experience and does not reflect the truth as each company or person can have different opinions.

What I’m going to cover here is:

• Why do companies do technical interviews
• The interviewer
• Candidates
• Hiring processes

Why do companies do technical interviews

There’s no regulation on the IT industry like on other as Medicine where professionals need to pass a test and prove they’ll not kill someone. Unless you’re making a medical app or coding an aeroplane computer, you’re probably not putting anyone’s life in danger. You’ll most likely write code for a website or similar experience.

Even if there was a regulatory entity, the IT industry is so broad and fast-evolving that professionals will need to update their tests regularly. Also, by the time the test is ready, the technology is already outdated. To make sure a candidate know what their CV’s states, the best option for companies is to do their own tests.

To access the candidates’ skills the companies need someone to run those tests, that is when the interviewer comes into play.

The interviewer

Just thinking about interviewer most of the people will think about someone smart and want to make you fail.

When the interview is with more than one interviewer, there’s always the good cop and the bad cop.

But this image needs to be changed. The interviewer is there to be your friend and wants you to succeed.

If a candidate is called to an interview is because the company already identified potential and it is possible to hire you. So failing candidates for the sake of having fun doesn’t make sense as is expensive to keep doing interviews while the interviewer could be working on something else.

As a candidate, you are also doing an interview, you’re evaluating how the interviewer behaves. That behaviour is probably how the company culture is, so if you don’t identify yourself with the interviewer, you’ll possibly not adapt to the company’s culture.

People are different and have different likings, to don’t feel bad if you don’t identify yourself with the interviewer or company. This simply wasn’t your best option, so it is better to move on. Take the opportunity to learn from the experience and apply to your next interview.

Candidates

This topic is in plural on purpose, because I’m going to mention how I identify a good candidate, but more important than that is how to identify a great candidate.

I can enumerate a few skills to help me find good candidates.

• Knowledge - the candidate will show excellent expertise on technologies
• Communication - even people thinking that IT professionals work on their computers all the time, communication is vital for them to work with stakeholders and colleagues. No one works alone.
• Experience - it is essential to have experience on the tech stack they work with.
• Problem solver - humans are problem solvers by nature, and IT professionals take this to the next level by scaling the solutions.

Any candidate who can present those skills is considered a good candidate, but we can find better candidates if we evaluate a different set of skills.

• Learner - a candidate who presents learning skills can improve their knowledge with time.
• Curious - a curious person will never agree to repeat the same work over the years, they’ll always try to investigate and experiment new things.
• Teacher - there’s no point in learning new things if you can’t share your knowledge. So sharing is an excellent way to learn and upskill other people.
• Passionate - when someone has a passion for what they do, they’ll never say TGIF because they love to work. There are no impossible challenges for passionate people.

Now that we know what to identify on the right candidate, let’s see how we can do that.

Hiring processes

Usually, companies are very creative in their hiring processes, the problem with that is that they start to be complicated.

When a process is too complicated, it takes time, leading the candidate to withdraw. With the competitive market, we live nowadays, we need to be quick to hire the best candidates. Unless you are one of the major IT brands in the world.

So far, I worked for two companies as an interviewer. Perhaps I am biased, but their hiring processes are straightforward.

The first one is composed of 5 steps.

• Technical puzzle - this is an in-house fully automated puzzle where the candidate generates a token, write their code and submit to the system. There’s no human interaction, hence there are no costs to filter candidates who do not have the minimum experience.
• Live coding challenge - remote 30-minute code exercise where the candidate will use their own computer and IDE with the opportunity to show their coding skills. Usually, the task is to debug a broken app.
• Technical interview - remote or in-person chat about the candidate’s technical knowledge. This chat will most likely be driven by the candidate, depending on how they answer the questions.
• Management interview - this stage is non-technical with a manager and a people & culture person. They’ll make sure the candidate is aligned with the company values.
• Offer!

That process is pleasant, straightforward, but it lacks a formal way to identify great candidates, relying only on interviewers feeling.

The second process has a significant step to try to identify the great candidate skills.

• Phone screening - as the name says, this is a phone call where the interviewer will try to filter out the candidates who don’t have minimal experience.
• Technical interview - this step can take up to 1.5 hours and is composed of a code challenge and technical discussion.
• Behavioural interview - that’s when the interviewer is focused on identifying great candidate skills with non-technical questions.
• Cultural interview - interviewers from a different department will access the candidate based on the company’s values to make sure they are a good fit.
• Offer!

As you can see, both processes are simple and straightforward, they also have their flaws.

Now you’re probably asking yourself if I know those processes have flaws and know which part is better on each one. Why not change and make a better one?

Changing a hiring process is not easy, there’s a lot of people involved, and you need to justify why it should be changed and how to improve. Later you’ll need to evaluate if the results are valid or not and continue adapting.

I don’t care about the context, show me the solution!

Last week my father sent me a message asking if I could build an electronic spreadsheet of the following image.

Looking at the image I promptly reply with “Can’t you use Excel for this?”

Then when I got home I opened my Excel and started to create a simple plan with the data from the image and that’s when I saw the notes.

This note says “Days = Difference between previous and actual date”. This was the moment when my Excel skills failed me! I tried to create a form input, but my research led me to some Visual Basic code and good old visual designer which I don’t want to play with it anymore. So I stopped and put some thinking on the issue.

• “What are my options?”
• “What do I know?”
• “This thing need to work on an offline environment” - There’s no internet where he use this

Building a desktop app means I’ll need to create a setup, send to him, control the installation and updates. So is not a good option. A web page seems simpler to solve the deployment, I’m currently working with React, so no learning curve.

Based on this I though about doing an PWA app.

According to Wikipedia this is a list of things your app should tick to be called as PWA.

• Progressive - Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
• Responsive - Fit any form factor: desktop, mobile, tablet, or forms yet to emerge.
• Connectivity independent - Service workers allow work offline, or on low quality networks.
• App-like - Feel like an app to the user with app-style interactions and navigation.
• Fresh - Always up-to-date thanks to the service worker update process.
• Safe - Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
• Discoverable - Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
• Re-engageable - Make re-engagement easy through features like push notifications.
• Installable - Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
• Linkable - Easily shared via a URL and do not require complex installation.

With that in mind, let’s go to my solution.

1. The App

To create the app I used the Create React App project from Facebook. The output is a basic app with a service worker in place. So with a simple command I can check some items from the PWA list.

• Connectivity independent
• Fresh

This is really nice, but still have some checkboxes to tick.

2. Bootstrap

The app looks nice but it does nothing. Knowing I’ll need to create a simple form for data input and a table to show the data, I’ve pulled the Bootstrap 4 package and changed the inport from index.html.

And now I can tick one more item.

• Connectivity independent
• Fresh
• Responsive

That’s really nice, I have an app with 3 checkboxes ticked, but what about the functionality? It’s time to write some code.

3. React App

I’m not going into much detail here, it’s not the intention of the post.

The app consists in a form with three fields pushing into an array and a table with the array contents.

All work fine, but what about persistence? I need to save this data somewhere.

4. Firebase

After a quick research I’ve choosed Firebase to persist my data. It has a service called Realtime Database where I can save documents. It’s Javascript SDK has support for offline access and syncronization, so I don’t lose my Connectivity independent tick.

The next challenge is to integrate Firebase SDK to React, that’s when come in handy a simple package called Re-Base, it’s integration is very easy and I only needed to write a few lines of code to have everything in place.

After that integration I could say the app was ready. It was saving the data online and offline. Most importantly was the syncronization happening when connection was restablished. Because the app have a service worker registered, I don’t need to open the app to syncronize, it just works.

With the data being saved online, now was time to secure the data.

5. Authentication

To solve the Autentication issue Firebase came in handy again. It’s SDK has auth integration with Firebase Authentication, so I only needed to build a simple account creatiion form and a login page. After that I configured my database security and it’s all in place, each user has access only to their data.

To have another checkbox ticked I need to solve the hosting.

6. CI/CD

To deploy my code as easly as possible I choosed Netlify as it can integrate with a Git repository and do the deployment. When configuring the app Netlify could identify it was a Create React App application and suggested me the build command. So it was a next>next>finish experience to have my site up and running on my custom domain with a Let’s Encrypt certificate.

After that I was able to tick on last checkbox

• Connectivity independent
• Fresh
• Responsive
• Linkable
• Safe

The Result

At the end I spend less than a full day of work of my free time build a fully function app hosted on a HTTPS address with online database and offline capabilities.

If you’re curious, below are a couple of screen shots. The source code can be found on Github.

The ChatBot started simple answering questions related to sessions and speakers. It returns an adaptive card with all information about each session.

Having all sessions wasn’t enough, so I added integration with QnAMaker, just in case a user asks about something not related to the sessions.

At this point, I wasn’t happy yet, so I went one step further and added integration with Bing search to make sure the user will always receive an answer.

So far so good, what can go wrong? I was using adaptive cards, the content looked great, all information was there, I was covering FAQs and a fallback to Bing search.

Before the conference starts, I asked my colleagues to test the Bot, is always good to ask someone else test your code. The testing data improved the LUIS model, and answers get better.

That’s when I started to realise that I needed to improve some things. The first one was the responsiveness. Yes, a ChatBot needs to be responsive. It needs to work on desktop and mobile since I wasn’t integrating with any app, the web interface required to be responsive.

So first tip: A ChatBot will not save you from the multi resolution devices issue, it is a lot simpler to solve though.

With the responsiveness solved, I figured out another problem. The conference agenda has changed. Yes, this is an issue, cause I decided to use a local JSON file with all the data, this means I needed to check the whole agenda and update my file, luckily it didn’t change much, and it was easy to update.

At this point, I was pretty confident with the Bot, from all the feedback I received from my colleagues the major ones were easy to fix, and others were just a case to train the LUIS model. So I started to make improvements and have better cards which show more data from the speaker.

When the conference started, and I was happy with the usage, till I find the first issue. The agenda has changed again. I just figured out when an attendee came to me asking about a session supposed to be in a room but was a different one. I promptly checked with the bot and the data was matching with his printed agenda, but after checking the website, I realised it was wrong again. At this point how do I update the agenda without a laptop? No luck here, I tried to stop thinking about it and enjoyed the conference. We can’t win all the time.

On the next day, I was free in the morning, so I brought my laptop and updated the agenda quickly, that’s when I realised that having too much data from a session wasn’t working well, sometimes the results weren’t displaying correctly.

Here it comes the next tip: When showing multiple results, make sure they all have similar content.

This day I missed the first session working on the result cards and added another result view based on the speaker. With the new cards, the result was consistent, and the user could click on a button to show extra information.

Overall the experience was positive, and I’ll do it again, with some different decisions.

And one last tip: A conference agenda is always changing, so is the website does not use an API, make sure you have an easy way to update your data.