DEV Community: Peeyush Kant Misra

Your AI Agent Can Call APIs Now

Peeyush Kant Misra — Mon, 21 Sep 2026 03:25:48 +0000

Your AI Agent Can Call APIs Now. Who Is Checking What It Does?

The real problem with agentic AI isn't giving an LLM tools. It's
controlling what happens after you give it access.
Imagine you give an AI agent access to:

your GitHub
your database
Slack
Jira
AWS
email
internal company APIs

And then you tell it:

"Fix the production issue."

The agent doesn't just generate text anymore.

It can *read data, call APIs, create files, modify code, open pull requests, send messages, and potentially trigger real-world actions.
*
That's incredibly powerful.

But it creates a new question that we don't talk about enough:

When an AI agent has permission to act, who decides what it is actually allowed to do?

This is where MCP, authorization, runtime verification, and agent security become extremely important.

And this is quickly becoming one of the biggest engineering problems in the agentic-AI era.

From Chatbots to Agents

A traditional chatbot mostly follows this pattern:

User
  ↓
LLM
  ↓
Response

You ask:

"Explain Kubernetes."

The model generates an answer.

An AI agent is different.

It can look more like this:

> User
>   ↓
> AI Agent
>   ↓
> Reasoning
>   ↓
> Choose Tool
>   ↓
> Call API
>   ↓
> Observe Result
>   ↓
> Reason Again
>   ↓
> Call Another Tool
>   ↓
> Take Action

The important change is the final step.
The model isn't just telling you what to do.

It can potentially do it for you.

That's the fundamental shift behind agentic AI.

The Tool Is Where Things Get Interesting

Suppose we give our agent three tools:

search_database()
send_email()
create_github_pr()

The LLM might decide:

User request
     ↓
"Investigate failed deployment"
     ↓
search_database()
     ↓
Find error
     ↓
create_github_pr()
     ↓
Fix proposed
     ↓
send_email()
     ↓
Notify developer

From the user's perspective:

"The AI fixed my problem."

From the infrastructure's perspective:

An AI-controlled identity just accessed multiple systems and performed multiple actions.

That's a very different security problem.

Enter MCP

This is one reason Model Context Protocol (MCP) has become so important.

MCP provides a standardized way for AI applications to interact with external capabilities such as tools and resources.

Instead of building a completely custom integration for every AI application and every service, MCP gives developers a common protocol for exposing capabilities to AI systems.

The protocol has evolved significantly in 2026. The July 28, 2026 specification introduced a stateless protocol core, improved authorization mechanisms, cacheable discovery results, Tasks, and an extensions framework designed for a more production-oriented ecosystem.

But here's the important distinction:

MCP can standardize how an agent interacts with tools. It does not magically make those interactions safe.
And that's where things get complicated.

Giving an Agent a Tool Is Giving It a Capability

Consider this MCP tool:

{
  "name": "delete_user",
  "description": "Delete a user account",
  "inputSchema": {
    "type": "object",
    "properties": {
      "user_id": {
        "type": "string"
      }
    }
  }
}

Technically, your agent can now call:

delete_user("user_123")

But should it?

That's a different question.

The LLM might have permission to discover the tool.

That doesn't necessarily mean it should have permission to execute the tool.

And even if it can execute it, maybe the operation should require:

User confirmation
       ↓
Policy check
       ↓
Authorization
       ↓
Tool execution
       ↓
Audit log

That's the layer we're going to need more of.

The Problem With "The LLM Will Decide"

One dangerous architecture looks like this:

User
  ↓
LLM
  ↓
"Seems safe"
  ↓
Tool
  ↓
Production System

We're essentially asking the same system that decides what action to take to also decide *whether that action should be allowed.
*
That's not a great security boundary.

A better architecture separates these responsibilities.

                    ┌───────────────┐
                    │     User      │
                    └───────┬───────┘
                            ↓
                    ┌───────────────┐
                    │   AI Agent    │
                    └───────┬───────┘
                            ↓
                    ┌───────────────┐
                    │ Policy Layer  │
                    └───────┬───────┘
                            ↓
                  ┌─────────┴─────────┐
                  ↓                   ↓
            Allowed?             Blocked?
                  ↓                   ↓
              Execute               Stop
                  ↓
             Tool / API
                  ↓
             Audit Log

The key idea:

The LLM proposes. A deterministic control layer decides.

Why This Matters With MCP

Current DEV discussions are already moving beyond simply "How do I build an MCP server?" toward questions such as:

How should MCP tool calls be verified?
How should agent permissions be enforced?
What happens when an MCP server is malicious?
How do we prevent tool abuse?
How do we audit autonomous actions?

DEV currently has an active trend around AI-agent security and authorization, including posts on MCP tool-call policy gates and malicious MCP server supply-chain risks.

That's a significant shift.

The conversation is moving from:

"Can agents use tools?"
to:

"Can we safely let agents use tools?"

Think About an AI Agent Like a New Employee

Here's an analogy I really like.

Imagine hiring a new developer.

You wouldn't give them:

AWS admin
+
Production database
+
GitHub organization owner
+
Company email
+
Payroll system

on their first day.

You'd give them limited permissions.

Maybe:

GitHub → Read + PR creation
Database → Read-only
AWS → Development account
Production → No access
Email → No access

And you'd monitor their actions.

AI agents should be treated similarly.

Instead of:

Agent = Administrator

we should think:

Agent = Identity + Capabilities + Policies + Audit

Least Privilege Becomes Even More Important

Traditional security already follows a principle called:

Least privilege
Give a user or service only the permissions required to perform its job.

For agents, this becomes even more important because an agent can potentially chain multiple tools.

For example:

Tool A → Read customer data

Tool B → Create document

Tool C → Send email

Individually, these capabilities might appear harmless.

But combined:

Read sensitive customer data
        ↓
Put it into document
        ↓
Email document externally

The dangerous behavior may not exist inside any single tool.

It can emerge from tool composition.

That's one of the biggest security challenges in agentic systems.

And Then There's the MCP Supply Chain

Here's another problem.

Developers can install or connect MCP servers created by third parties.

That means we're introducing something similar to a dependency ecosystem.

Think about npm packages.

You don't blindly trust every package because it has a nice README.

The same principle should apply to agent tools.

A malicious or compromised MCP server could potentially become part of an agent's execution environment.

That is why current developer discussions are increasingly focused on MCP supply-chain security and trust.

The New Security Stack

I think production agent architectures will increasingly look something like this:


                 ┌──────────────────┐
                 │      User        │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │    AI Agent      │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │ Policy / Guard   │
                 │      Layer       │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │ Authorization    │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │      MCP         │
                 └────────┬─────────┘
                          ↓
             ┌────────────┼────────────┐
             ↓            ↓            ↓
          GitHub        Database       AWS
             │            │            │
             └────────────┼────────────┘
                          ↓
                    Audit / Logs

This is much closer to how we should think about production agent infrastructure.

What Should Developers Actually Do?

If you're building an AI agent today, don't stop at:

agent = create_agent()
agent.add_tool(...)
agent.run(...)

Ask these questions instead.

1. What can the agent access?

List every tool.

GitHub
Database
Slack
AWS
Email
Filesystem
Browser

What can each tool actually do?

Don't just ask:

"Does the agent have access to GitHub?"
Ask:

"Can it read repositories?"
"Can it create branches?"
"Can it merge PRs?"
"Can it delete repositories?"

Those are very different capabilities.

3. Which actions require confirmation?

For example:

Read database          → automatic
Create draft PR        → automatic
Merge PR               → confirmation
Delete production DB   → impossible
Send external email    → confirmation

4. Can you audit every action?

You should be able to answer:

Which agent?
Which user?
Which tool?
Which arguments?
Which resource?
When?
Why?
What happened?

If you can't answer these questions, debugging an autonomous system becomes extremely difficult.

The Interesting Future

MCP is evolving beyond a simple way of connecting an LLM to a tool.

The 2026 specification is explicitly addressing things such as authorization, scalability, long-running tasks, extensions, and lifecycle management.

And the ecosystem is exploring mechanisms around stronger trust and auditability as well; the MCP proposal tracker currently includes proposals related to signed capability declarations, tamper-evident audit records, asynchronous tool approvals, and signed execution records.

That's an interesting signal.

Because eventually the question won't simply be:

"What tools can my agent use?"
It will become:

"What capabilities does this agent have, who authorized them, what did it actually execute, and can I prove it?"

That's an entirely different level of AI engineering.

The Mental Model I Want You to Remember

Don't think:

LLM + Tools = Agent
Think:

LLM
 +
Memory
 +
Tools
 +
Permissions
 +
Policies
 +
Observability
 +
Human approval
 =
Production Agent

The model is only one component.

The system around the model is what makes an agent useful—or dangerous.

Final Thought

We're entering an interesting phase of AI development.

The first wave of AI engineering was about:

"How do I make the model smarter?"
Then came:

"How do I give the model access to my data?"

Now we're asking:

"How do I let the model take actions safely?"

That is the real engineering challenge of agentic AI.

Because once an AI can call your APIs, access your data, modify your code, and interact with the real world...

the question isn't whether the agent can act.

The question is whether you can control, verify, and audit what it does.

And that's why AI-agent security may become just as important as the agents themselves.

📊 Logistic Regression in a Nutshell

Peeyush Kant Misra — Sat, 24 Feb 2024 05:37:24 +0000

🧠 Introduction:

Definition: Logistic Regression is a statistical method used for binary and multiclass classification in machine learning.
Objective: Predict the probability of an instance belonging to a specific class.

📈 Key Components:

Sigmoid Function (Logistic Function):
Role: Maps any real-valued number to the range [0, 1].
Decision Boundary:
Definition: Threshold determining class assignment.
Log Odds:
Calculation: Transformation of probability values.

💡 How It Works:

Step 1: Calculate the weighted sum of input features.
Step 2: Apply the sigmoid function to obtain probabilities.
Step 3: Set a decision boundary to classify instances.

🎯 Use Cases:

Spam Detection:
Application: Classify emails as spam or not.
Disease Diagnosis:
Application: Predict disease presence based on symptoms.

🌐 Advantages:

Simplicity: Easy to implement and interpret.
Efficiency: Performs well on linearly separable data.

🚫 Limitations:

Linearity Assumption: Assumes a linear relationship between features and log-odds.
Sensitive to Outliers: Can be influenced by extreme values.

📊 Conclusion:

Logistic Regression, despite its name, is a powerful classification tool widely used for its simplicity and effectiveness in various real-world applications.

🤖 Embrace Logistic Magic in Classification! 🌐🔍

Do you want to connect and chit-chat with me???

Buy me A Coffee🍵
You can find me on Instagram 🤝
Join my WhatsApp Channel💬
Also want to learn tech or development, then subscribe to me on YouTube

Demystifying the Path: Your Roadmap to Becoming a Machine Learning Engineer

Peeyush Kant Misra — Tue, 13 Feb 2024 12:42:48 +0000

The allure of Machine Learning (ML) is undeniable, holding the potential to revolutionize industries and unlock hidden insights. But for aspiring engineers, embarking on this journey can feel daunting. Fear not, for this roadmap will guide you through the key steps, transforming you from a curious novice into a confident ML practitioner.

Step 1: Laying the Foundation:

Programming Prowess: Master Python, the lingua franca of ML. Start with basic syntax, data structures, and algorithms, then progress to libraries like NumPy, Pandas, and Matplotlib for data manipulation and visualization.
Mathematical Musings: Brush up on your linear algebra, probability, and statistics. These concepts form the bedrock of ML algorithms, helping you understand their inner workings and choose the right tool for the job.

Step 2: Unveiling the ML Landscape:

Conceptual Clarity: Explore fundamental ML concepts like supervised learning, unsupervised learning, regression, and classification. Get familiar with different algorithms like linear regression, decision trees, and random forests.
Hands-on Exploration: Dive into online courses, tutorials, and MOOCs (Massive Open Online Courses) like Andrew Ng's "Machine Learning" on Coursera. Practice implementing algorithms on real-world datasets through platforms like Kaggle.

Step 3: Deepening Your Expertise:

Statistical Savior: Delve deeper into statistics, mastering hypothesis testing, feature engineering, and model evaluation techniques. Understanding how to assess your model's performance is crucial for making informed decisions.
Model Mastery: Graduate to more complex models like Support Vector Machines, Neural Networks, and Deep Learning. TensorFlow and PyTorch are popular frameworks for building and training these models.

Step 4: Engineering Excellence:

Data Wrangling Wizard: Learn data cleaning, preprocessing, and feature engineering techniques for preparing raw data for analysis. Tools like SQL and cloud platforms like AWS or Google Cloud can streamline this process.
Deployment Dojo: Explore model deployment options like web applications, mobile apps, and APIs. Familiarity with cloud platforms and containerization technologies like Docker can be valuable assets.

Step 5: Continuous Learning:

Stay Ahead of the Curve: ML is a rapidly evolving field. Stay updated by reading research papers, attending conferences, and participating in online communities.
Never Stop Building: Your portfolio is your calling card. Showcase your skills by working on personal projects, participating in hackathons, and contributing to open-source projects.

Conclusion: Your Step-by-Step Guide

Remember, this roadmap is a guide, not a rigid script. Adapt it to your pace, interests, and resources. With dedication, perseverance, and a love for learning, you'll conquer the exciting world of Machine Learning and make a mark on the future.

Do you want to connect and chit-chat with me???

Buy me A Coffee🍵
You can find me on Instagram 🤝
Join my WhatsApp Channel💬
Also want to learn tech or development, then subscribe to me on YouTube

Choosing Your Weapon for Competitive Programming and DSA

Peeyush Kant Misra — Mon, 29 Jan 2024 13:42:15 +0000

Greetings, fellow code warriors! Ready to conquer those coding challenges and master data structures and algorithms (DSA)? Today, we’re facing a crucial decision: which programming language will be your trusty sword in the online coding arena? Will it be the swift C++, the versatile Java, or the Python charmer? Let’s dive into the battle of the languages!

C++: The Speed Demon

Unparalleled Performance: C++ is the undisputed king of speed. It’s like a lightning bolt in a bottle, executing code faster than you can say “runtime error.” Think of it as that sleek sports car that leaves the competition in the dust.
Total Control: C++ gives you granular control over memory management and system resources. It’s like being a coding mechanic, fine-tuning your code for optimal performance. Perfect for those who love to tinker under the hood.
Steep Learning Curve: But like any high-performance machine, C++ demands a skilled driver. Its syntax can be strict, and its error messages unforgiving. Prepare for a challenging yet rewarding journey if you choose this path.

Python: The Elegant Problem Solver

Readability and Simplicity: Python’s code reads like a well-written novel, clear and concise. It’s like coding in your native language, making it perfect for beginners and those focused on problem-solving logic.
Vast Libraries and Tools: Python’s ecosystem is a treasure trove of libraries and tools for data manipulation and analysis. It’s like having a magical toolbox at your fingertips, ready to tackle any DSA challenge.
Speed Trade-offs: Python’s ease of use sometimes comes at the cost of raw speed. It’s like choosing a comfortable cruiser over a race car. But for many DSA tasks, Python’s efficiency is more than enough.

Java: The Reliable Workhorse

Object-Oriented Powerhouse: Java reigns in large-scale applications and competitive programming. Its object-oriented design promotes code organization and reusability, like building a well-structured fortress for your algorithms.
Cross-Platform Compatibility: Java code runs smoothly on different operating systems, making it a versatile choice for diverse challenges. It’s like owning a universal adapter for your coding skills.
Verbose Syntax: Java can be a bit wordy, demanding more typing than its concise counterparts. Think of it as being extra cautious with your blueprints before building a mighty fortress.

The Verdict: Choose Your Champion Wisely

The best language for you depends on your priorities and preferences:

Speed and control freaks will find their soulmate in C++.
Beginners and problem-solving enthusiasts will adore Python’s simplicity.
Structured thinkers and cross-platform explorers will appreciate Java’s reliability.
Ultimately, the key is to master the fundamentals of DSA, regardless of language. Once you grasp those core concepts, switching between languages becomes much easier. So, experiment, find your favorite coding style, and conquer those challenges!

P.S. Don’t forget to practice regularly, participate in online coding contests, and join coding communities to hone your skills and make new coding friends! The coding world is yours to explore!

Do you want to connect and chit-chat with me???

Buy me A Coffee🍵
You can find me on Instagram 🤝
Join my WhatsApp Channel💬
Also want to learn tech or development, then subscribe to me on YouTube