Autonomous agentic systems break this paradigm entirely. An agent does not follow hardcoded logic; it interprets, plans, loops, and acts. Faced with an identical prompt, an agent may react completely differently; it might query a database today, call a shell script tomorrow, or hallucinate an entirely nonexistent API endpoint next week. To improve explainability and also, to pretend to know what the hell is going on, we have the agent’s chain-of-thought thrown into this mix too. Basically CoT means the model/agent documents exactly how it reached the result. To fully understand what’s going on we have to use logs for our agent, what it accesses, how it thinks, how it’s authenticating and finally what is it doing.

This also increases the attack surface of an agent as now it isn’t just limited to the assets and data it has access to but also it’s own Chain-of-Thought and Memory.

Some challenges faced in SOC due to the new attack surface:

The sheer volume of data

Just think about it, we have AI Assistants like Claude, AI-enabled Browsers like Perplexity, AI-enabled software like Harvey AI or even Jira and SNOW, MCPs, LLM Endpoints etc. If each person in a 50 person company runs 5 sessions/day it’s almost 250 log events to be monitored across each software, so increasing the amount of logs generated and ingested by almost 150%. By the way, we haven’t even considered OT and IoT devices running manufacturing AI algos or BMS in the mix yet for Enterprise monitoring.

The most difficult question: What to monitor?

OWASP Top 10 for Agentic and LLM covers different vulnerabilities across different Responsible AI tenants. Alerts related to bias or cascading bias, hallucination or agent goal hijack related alerts are required to be sent to the dev team for remediation. If these alerts, reach a SOC team, it’s practically useless because a SOC team manages the incidents for the enterprise and hallucination, bias is specific to the use case only. The dev team responsible for the use case or app can only fix the performance based vulnerabilities. Any prompts where PII data wasn’t properly obfuscated or the outputs show PII/PHI data that it shouldn’t, need Data Privacy Office to review. They determine how to handle the incident.
Prompt Injection and Privilege Escalation etc need the security team to intervene and stop.

At the same time non GenAI or LLM related algos running may have different criteria for monitoring. For example: a team working on an self-driving car, they don’t need to monitor for privacy and security in the traditional sense. The monitoring parameters would be with the perspective of the environment, visibility, detection, control, driving etc. Thus, for general consulting companies or manufacturing companies, the monitoring of an AI system for safety and security is totally different.

Thus, the segregation of events and alerts require a thoughtful framework to be created with each team requiring different data parameters for their review and analysis. Currently no products or even guidelines from any orgs are available in the market to help companies differentiate between log collection and actionable alerting.

The Payload Paradox and Legal challenges

Following up from the previous point we have the payload paradox brought to you by the non-deterministic autonomy of an agent.

Since the agent can take actions on it’s own and their actions may differ for each case, to detect adversarial goal hijacking, developers and security analysts need total forensic visibility into the agent’s chain-of-thought traces, prompt templates, and intermediate tool arguments. Yet indiscriminately dumping all raw execution spans into telemetry pipelines turns the observability stack into a high-risk data liability, aggregating unredacted PII, enterprise secrets, and compliance violations into single, queryable buckets.

Not only does logging everything increase risk but also not logging everything raises several issues in cases of legal hold or court/gov inquiries, once litigation is reasonably anticipated, the duty to preserve potentially relevant evidence extends to AI interaction logs the same way it extends to any other record so “we didn’t think to keep it” is not a defense.

Multimodal inputs

For certain models like LLMs or object-detection (YOLO), the input and payload format received are varied. An LLM accepts video, audio, text, image inputs which requires subsequent calibration for the alert rule. For images, we need to keep in mind about steganography. For audio, we have to consider privacy declarations before even considering ingestion of logs. Other systems with YOLO models will have sensor input which will be processed completely differently from user facing apps providing text or so responses. This overall increases the complexity as there is no common baseline to go from and most integrations requires further nuances to set up credible alerts.

Legitimate vs Malicious events for General Purpose apps

For general purpose AI apps like Claude ort ChatGPT, the use cases that a user can do are countless. One can generate essays, analysis website UI or even do gene computation. Now, how do you determine at a very large scale with just logs what is malicious activity? If a user is leveraging Claude Cowork for editing a video, the agent might create multiple temp image files during processing in the folder and then delete them all. In the logs, it may come across as mass deletion which needs further review on account of it being insider threat. With such general purpose apps, determining use cases that are truly malicious are difficult and may need to be regularly updated.

Trust in CoT

As mentioned earlier in the article, we depend on Chain-of-Though to understand the agent behavior. However, as the agent documents it’s own actions, it raises a questions that if the logs are actually accurate.

Referencing specifically the model system card published by OpenAI for Astra, we see that chain-of-thought faithfulness and accuracy has been chipping away and the picture in 2025–2026 is not encouraging. Models can produce a plausible, coherent-looking rationale that has little to do with the actual computation behind an answer. The stated reasoning and the real decision process can come apart, especially under biased or leading prompts, as Turpin et al.’s original work demonstrated and later studies have replicated. A 2025 study from Anthropic researchers found that reasoning traces verbalize a hint the model actually relied on in fewer than one case in five where the hint was used at all. Anthropic’s own paper on chain-of-thought monitorability is candid about this: CoT is a genuinely valuable safety signal, but a fragile one, subject to exactly the same pressure to look helpful and harmless as any other model output.

There’s a term for the failure mode that’s started circulating in the literature: reasoning theater. A model can already “know” the answer and still generate tokens that perform the appearance of working it out.

This matters enormously for the audit-trail pitch, because an audit log that doesn’t reliably reflect what happened isn’t an audit log. It’s a transcript of a performance. Worse, a security researcher pointed out that the failure mode is exploitable in the other direction too: an adversary can craft prompts that produce a coherent-looking reasoning trace that steers toward an attacker’s preferred conclusion, without ever triggering the safety classifiers built to inspect reasoning for red flags. The very layer you’re trusting to catch misbehavior can be dressed up to pass inspection.

This concludes the challenges a SOC team may face when they try to setup effective monitoring and alerting for AI and agentic systems. Everytime you think of AI systems, make sure it’s not just boxed to GenAI/LLM systems but also systems leveraging other algos like Building Mangement Systems that run ML models or Face scan systems that use Object-detection algos (YOLO).

AI Agents vs Automation: What is the difference

Firstly, what is an AI agent, and why is it different from our plain ol’ automation? Automation follows a set of predefined rules to complete tasks—fast, consistent, and predictable. AI agents, on the other hand, operate with autonomy: they can reason, adapt, and make decisions based on dynamic inputs. For eg: if the goal is to parse a document and then send a mail with the extracted data. If we create an automation script, we would need to first use a parsing algo and then define words that need to be extracted using key-value pairs or regular expressions. After that, we also need the exact template with substitutions defined for the mail to be sent. Whereas if we create an AI agent, we need to use an algo focused on extraction and just define the expectations, like write a mail with a formal tone or make sure the mail is concise. The agent will use its autonomy to draft the mail and send it. Both the AI agent and automation script would still need access to the mailbox, permission to read the doc, permission to send the mail and authentication credentials. Pretty cool to see how far NLP algos have come but also a bit terrifying.

Challenges we may see if we use SOC-AI agents:

1. One of the key challenges AI researchers are working on is Explainability. According to ISO/IEC TR 29119-11:2020, it means the level of understanding how the AI-based system came up with a given result. Let me elaborate with an example: If we consider a decision tree algo or K-means, as a researcher/developer, one can look at the input and give a reasonable guess why a certain output was derived. But what about LLMs or Facial Recognition algos like FaceNet, at any given point a researcher or expert cannot say with certainty why a certain output was derived. You can try it yourself if you ask Claude to write 5 sentences on any topic, like “Tell me about the movie Jurassic Park.” Now, how can you say with certainty what 5 points it will cover? It can talk about actors, directors, movie reviews, CGI or anything.

This is different from interpretability, which is basically the level of understanding how the underlying (AI) technology works, which we can explain, like Claude is an LLM which is based on Transformer architecture. Or FaceNet uses a deep convolutional neural network to learn a mapping/embedding from a set of face images to a 128-dimensional Euclidean space and assesses the similarity between faces based on the square of the Euclidean distance between the images’ corresponding normalized vectors.

So in the context of SOC agents who have more autonomy, tool access, LLM access, etc., how do we account for explainability in a way that is accessible to all the analysts?

2. The idea that the system responsible for monitoring everything and generating alerts uses a mix of probabilistic and deterministic algos to derive answers is a bit scary. The probabilistic algos come into play during the first half, where the agent tries to assess the telemetry for context. They apply behavioral baselines and knowledge graphs to assign risk scores and dynamically select response paths based on asset criticality, rather than following fixed “if X, then Y” rules. As you may know, any system is not 100% accurate, and a probabilistic system may lead to errors that have a huge impact on business. Not a big deal in the grand scheme of things, but has anyone noticed that since we started using AI agents for coding in corps like AWS and Microsoft, there have been more outages? Big organizations may be able to absorb the impact, but smaller orgs will face more challenges.

3. With AI being the IT-girl of the industry, it is also the prime target of hackers. The constant attempt to use AI agents or shared LLMs for attacks and malware propagation is very real. Imagine the system you depend on for alerting you of these incidents and exploits and attacks itself gets compromised because of a shared model or Agent-to-Agent sprawl or even a sci-fi-style rebellion.

4. Lastly, since AI agents have more autonomy, their mistakes are also unpredictable. As per many experts across domains, note that the agent is generally reliable and doesn’t make errors, but when it does, it’s pretty hard to trace the error because the steps taken aren’t logged. In a controlled environment, with limited variables or just 2-3 use cases, it is still manageable, but in prod, where the SOC system handles 1000s of use cases and logs, attack signatures, etc., things become challenging. Also, the butterfly effect, where a small mistake is insignificant in itself, may lead to business outages or legal repercussions.

Then what is the solution? Because analyst fatigue is real, and with fixed security budgets, any help is appreciated. The solution is human-in-the-loop, where the analyst uses SOC for summarization, data extraction, references, and alert generation, but at the end of the day, the analyst makes the final call to dismiss or act on the alert.

Before you start: scope and the shared responsibility model

Choosing a reliable Cloud Service Provider (CSP) with a proven track record of good service and customer support is the first step. AWS, Azure and GCP are the top picks for most teams. For China, Alibaba Cloud, Huawei Cloud and Tencent Cloud are the top picks. For startups and people deploying hobby projects, you can look into DigitalOcean and Vultr (40-50% cheaper for small and mid workloads) or companies like Vercel, Supabase, Cloudflare that offer IaaS (read about it in the next few para). OVHcloud, Hetzner and Scaleway offer European data sovereignty, cheap, reliable, secure but customer support is pretty questionable.

Before onboarding any vendor, do your due diligence: check their certs and third-party audit reports (SOC 2, ISO 27001, 27701 etc), review their SLAs and support promises, and most importantly compliance to any regional laws (think GDPR for EU, California’s CCPA/CPRA, India’s DPDPA China’s PDPL etc).

Now let’s discuss the 4Ws: Who’s paying, what does the provider own, what do you own, and what’s pros/cons. Seriously nothing is 100% reliable and safe so writing what works and what doesn’t really helps to understand who is left with the bill and heavy luggage if things go south.

Let’s answer the remaining 2Ws: what does the provider own and what do you own. The simple answer is IaaS vs PaaS vs SaaS. Simply put cloud works on a shared responsibility model which means the provider and you both take care of certain aspects. This image will help you:

Use IaaS model with PaaS services (this is not either or so you can choose and mix match yaaay! the best of both worlds), when you’re setting up your own ap or creating a SaaS to sell and what we’ll discuss here.

Phew, now to the actual app review. The three things to ask for first: an architecture diagram, a data flow, and a list of who has admin access.

• An architecture diagram should help you understand the components of the app and how they connect with each other. For cloud, usually each service has a separate icon based on the provider. Check out AWS refrences for examples.
• A dataflow diagram shows how the data flows through the app. If there is a logic of user logging into their account, the dataflow would denote: User entering creds -> the creds are sent to IdP or DB -> If creds match an auth token is generated -> token used to access user’s data stored in DB -> final user console visible to user.
• Admin access should be very restricted. Ideally not even one user, once project goes live. Next section gives the details.

Identity and access

In cloud, there are broadly 4 access types: Root, Admin, Contributor and User.

• Root Access is god-tier/full access. Think super admin. You can create subscription, change billing etc. It’s recommended by everyone that this access should only be used for initial setup, billing, new sub-tenant creation or closing the account etc basically very big stuff. If you use it for everything and somehow lose it or attackers get this access, you’re cooked and would need a miracle to save your money and app. So use lower access for 90% of the things.

• Then we have Admin Access, which allows you to do any action on any services or resources. Just not the account level stuff like billing change etc. You can use it for day-to-day operations.

• Contributor is like a Delegated Administrator for a specific role that manages certain services like Security Hub. Usually the best practice is the IT team or 1-2 people have the Admin access for operations and if any dev/project teams need elevated access Contributor access can be given for that specific subscription or a few services in the account.

• User level access is the basic read-write access. You can gives this primarily for dev teams that don’t handle infra.

We know the access levels broadly, so to give them? The answer is IAM User ( not to be confused with user level access). IAM User is the identity created within IAM to represent a person or application. By default, an IAM User has no permissions and must be explicitly granted access via attached policies. The idea is when a user or app is setup on cloud, an ID is created for them which allows them to work and take action on cloud. It’s not your company or personal ID like gmail.com but a specific ID only for your cloud tenant. You can decide what and how much access to be given for user. Single user accounts are used for apps, automations etc and for devs, IT login corporates can enable SSO using SAML 2.0 for user auth on portal.

Securing the IAM

(order: the console, service accounts, cloud service-to-service communication, devs connecting to infra, end user login)

• Set up SSO+MFA for user auth to resource console.
• Make sure service accounts/app accounts have bare minimum permissions to complete tasks essentially least privilege principle.
• Also, make sure each service account has someone responsible for managing it like updating password, storing the password properly so app can call the account etc.
• For authentication of services, try to use managed identities (platform manages the credentials.) or temp cred which are sent straight to compute resource based on role.
• In some cases long-lived keys are unavoidable if that is the case make sure the keys are stored securely in a vault.
• Token based auth (OAuth 2.0 or JWT) is generally used for API. Access tokens should be short-lived. A shorter life shrinks the window in which a stolen token is usable. Also, configure policies for refresh tokens for public clients (SPAs, mobile) like periodic rotation or sender constrained and ensure tokens are out of browser storage.
• For devs to login to connect to the EC2/VM etc usually people use SSH keys (store in a encrypted file on PC). For environments, that need more security go for Session Manager.
• For end users of the app (not devs and IT but actual users), set up SSO or username/password with MFA. Now, just a single username/password isn’t sufficient so MFA, password complexity, max retry attempts need to be setup.
• Lastly but most importantly, give access sparingly. Diligently and religiously follow least privilege principle. When in doubt just give user level access only. This goes for the console, services and the app. For app, implement role-based-access-control (RBAC), check out free software to help with it: Casbin and Casdoor for AI/LLM agents.

Network exposure

Since cloud follows a shared responsibility split, the provider manages the infra but you manage the access. In cloud, networking is based on using virtualized technologies rather than physical hardware. Software-Defined Wide Area Network (SD-WAN), Virtual Private Network (VPN), and Virtual Private Cloud (VPC) are the major technologies that help us secure cloud infra.

• VPN is something you would probably have heard of. VPN is basically encrypted tunnels to secure communication between devices or networks over the internet. In an eg: if a letter is the data, the envelope is the tunnel and the stamp is the auth key. Corporates usually setup their own VPN because it allows them to host and expose internal apps, platforms etc only to their employees. When you have an app that should be only accessed by employees of the company, one of the simplest way to reduce the attack surface is to IP lock the app to the IP range of the VPN. It basically means that employees would have to connect to the corporate VPN to be able to connect to the app. If we follow the letter example, basically IP Range is the postal code by mentioning that we ensure only letters of a certain area come to that post office.
• Virtual Private Cloud ( VPC) is the isolated network environment within a public cloud with it’s own subnet, IP range and route tables. When you request any resources like servers or databases, they’re automatically given to you in a VPC. All your requested resources will be in the same VPC. If you request a new service, you can decide to add it to a existing VPC or a new VPC. Some services are PaaS and when you request the services they come in a separate VPC with it’s own DB, LB, vault etc. To connect a PaaS service with your other resources you have to use VPC peering.
• Consider VPC your app’s home and you need to secure it properly using Network Security Groups (NSGs) and private endpoints. You need to lock it down.
  • Make sure that the app is not accessible to anyone and everyone over the internet (0.0.0.0/0).
  • Open only ports that you actually use like 443 for (HTTPS) or 5432 (PostgreSQL DB).
  • For SSH (22) or RDP (3389) connectivity for devs, use a bastion host or jump box. Never expose these ports directly to the public internet as these protocols allow us to connect to VMs/systems etc remotely.
  • Block access from known malicious IPs. Use AbuseIPDB and Project Honeypot for the list.
• If you’re app is exposed to the internet use a load balancer with WAF. This way the load balancer’s public IP is exposed and not your app. Add an APIM as well, if you have a huge app with loads of APIs.
• Use public endpoints with public IP for public internet facing traffic and private endpoints with private IPs (uses the provider’s backbone network) for all resource/internal traffic.
• What if the frontend of the app is on cloud but the DB is on-prem? In that case, we use the vendor provided direct cloud connectivity service. Think AWS Direct Connect, Azure ExpressRoute and GCP Interconnect. Basically these are network connections managed by the provider that uses a combo of MPLS, IPSec, broadband for good connectivity with SD-WAN for management. Very secure and very expensive so use it with a pinch of salt.

Data protection

Easiest to execute but most important section especially from compliance.

• Encryption at rest and in transit, everywhere data lives and moves. Server-side encryption is enabled by default by major cloud providers. For data in transit use TLS 1.2+ and for data at rest use AES 256 (industry best practice).
• Encryption options based on service:
  • Full-Disk Encryption (FDE) and Encryption at Host: Use for VMs and VDIs. FDE encrypts the entire storage device (e.g., BitLocker, LUKS). Encryption at Host provides end-to-end encryption from the VM host to the storage service.
  • Transparent Data Encryption (TDE): Use for DBs and provider managed DBs. Automatically encrypts database files in real-time without application changes.
  • File/Column-Level Encryption: Use for DBs and provider managed DBs storing PII/PHI data. Targets specific sensitive fields or files for granular control.
• Make sure the keys, certificates and creds for service-to-service auth are stored in a vault or HSM. You can use the CSP’s native vault service or checkout HashiCorp’s free tier license (not opensource so check the license). Also, make sure the whole key lifecycle: creation, usage, rotation, deletion has a policy to be followed.
• The keys can be generated by the provider or you or the client but store it in a vault.
• Passwords, API keys, tokens and connection strings shouldn’t be written directly into source files, config files, Docker images or CI scripts. Inject the passwords etc from the CI platform’s storage directly at runtime.
• If you use GitHub, use their push protection and secret scanning to intercept a push before the secret enters the repository.
• You can use scanners like gitleaks as pre-commit hooks or CI checks.
• Make sure your storage buckets are private and accessible only to authorized members (think devs maintaining the content and app to update records) via DLs . Crosscheck even if public access is disabled by default. If a bucket must be public (static website assets, say), keep it separate and confirm nothing sensitive is in it.

Logging and detection

• If you have a corporate SIEM, make sure all relevant logs are integrated. If you don’t have a SIEM, you can use the provider’s native monitoring service like AWS CloudTrail and Azure Sentinel or free-tier/cheaper vendor options like New Relic, Grafana Cloud , Datadog or open-source solutions (needs some underlying infra)like Grafana Loki and the Elastic Stack (ELK).
• Figure out the logs needed to be monitored like user access logs, admin activity logs, audit logs etc and push it to SIEM.
• Make sure retention is long enough to investigate something that happened months ago.
• Alerts should go to a real person who will see them, not a mailbox nobody checks.

Resilience

• Figure out RTO and RPO for the app. Recovery Time Objective (RTO) is the max acceptable downtime for a system or service after a disruption, basically how quickly operations must be restored. Recovery Point Objective (RPO) is the max acceptable amount of data loss basically the time between the last successful backup and the failure event.
• Once you have this, decide your backup strategy. Eg: backup the DB once a day and VM image once a week etc.
• Backups should be isolated from production, so one bad day can’t take out both.
• A backup you’ve never restored is a rumor. Test your backup copies for successful restoration.
• If your app is very critical, make sure there are at least 2 backups and in two different geographic regions.

Turning findings into fixes

Finally, we’re winding down. Run compliance scans and vulnerability scans on your cloud workloads. Categorize the findings business impact, not just CVSS. Make sure each finding has an owner, a date for closure and someone to check it (who’s not responsible for fixing it).

You don’t need to fix everything in week one. Get the map, follow the data, find the keyholders, then work through the five areas and rank what you find by how much damage it could do. Start with the things that are both easy to exploit and painful to lose.

And if someone says “it’s all fine” without a diagram to back it up, smile politely and ask for the diagram.

The core problem

AI is deeply embedded in our lives They can read files, call APIs, write to databases, send emails, and execute shell commands. This power comes with a category of risk that didn’t exist before: AI-initiated irreversible damage, triggered not by a human attacker, but by your own tool acting on bad instructions, misconfiguration, or plain ol’ manipulation.

I’m broadly categorizing the source or what may cause this damage into three distinct origins:

• Wrong prompts / misconfiguration — the user or operator creates conditions where the AI acts destructively with good intent. This also includes unintended consequences. Think The Streisand Effect or Macquarie Island (rabbits introduced for lost sailors to hunt when stranded ended destabilizing the island ecosystem).
• Hallucination in action — the model fabricates a confident but wrong plan and executes it. Happens to the best of us and models are no exception.
• Adversarial manipulation — prompt injection, supply chain poisoning, or MCP exploitation causes the agent to act against the user’s interests.

PocketOS: The 9-Second Production Wipe (April 2026)

One of the latest incidents which prompted me to write this article finally. PocketOS, a SaaS platform serving car rental businesses, was using Cursor powered by Anthropic’s Claude Opus 4.6 to work on a routine task in the staging environment. The agent encountered a credential mismatch and entirely on its own initiative decided to fix the problem by deleting a Railway volume. The deletion took 9 seconds. The agent had found an API token in an unrelated file; that token was created for managing custom domains via the Railway CLI, but its permissions weren’t scoped to those actions. Railway’s API allowed the destructive call without a confirmation step, and the platform stored volume-level backups on the same volume as the source data — so everything went at once. Link for an TechRadar deep-dive on this incident for anyone curious.

User looses data (#6657449328)

Some instances of people loosing their data due to mishaps and no backups:

• A user watched their dissertation, operating system, applications, and personal data get deleted while asking Cursor to find duplicate articles. Link
• Summer Yu, Meta’s Director of AI Alignment and Safety, went viral in Feb 2026 for tweeting that the AI agent OpenClaw deleted her entire Gmail inbox despite her explicit instructions to confirm actions first. Link
• Nick Davidov, a VC, tweeted that Claude Cowork accidentally deleted 15 years of family photos from his wife’s computer while attempting to organize her desktop. Link Yeah yeah, my initial source were the tweets but I can’t find them so here are some articles.
  Also, I don’t believe it’s the

Why this may happen?

I believe this is not an AI/LLM issue but a design flaw. The general setup of agents/AI tools is that it works in sessions. At the end of each session, the context is lost akin to our LLMs true nature of being stateless which basically just means that each inference call starts with a fresh context window, and the model retains no memory of prior interactions or intermediate computations once the call ends. So technically speaking our agents make a locally-coherent decision based on incomplete information for each prompt/iteration. Also, I feel we can not provide the optimum context anyways. If we take an example of deleting marketing mails from mailbox, banks send marketing mails and policy updates about credit cards etc so it is plausible for the agent to accidentally delete policy update or awareness mails or in case of e-commerce, delete the purchase receipts. As a user, I had not specified what is considered spam etc just to delete unimportant mails.

Let’s delve deeper into this based on each category:

1. Misconfiguration: The key structural difference: traditional systems fail according to their configuration. AI agents fail according to their reasoning about their configuration.

A misconfigured permission in a traditional system is dormant until exploited. A misconfigured permission in an AI agent’s context is a capability the agent may discover and apply autonomously in ways the operator never anticipated. The agent is, in a sense, doing creative problem-solving with whatever tools it can find — which is exactly what makes it useful, and exactly what makes misconfiguration so dangerous.

Secondly implicit vs. explicit scope. When you configure a traditional tool, you specify what it does. When you configure an AI agent, you specify constraints — and the agent operates in the space between them. That space is never fully specified, which means your configuration is always incomplete by design. Any gap in your constraints is potential autonomous action the agent may fill in with its own judgment. You’re not writing a program; you’re drawing a fence around a reasoning system, and the fence will always have gaps you didn’t see.

2. Hallucination By the way, researches have called it a feature not a bug so do with this info whatever you want. Hallucination is often described as “the model getting facts wrong,” which makes it sound like a reliability problem — similar to a buggy function returning the wrong value. That framing misses what makes it dangerous in agentic systems.

The structural difference is this: traditional software fails silently or noisily, but predictably. Hallucinating agents fail confidently and act on the failure.

A buggy function returns a wrong value. The system either catches it (error handling), surfaces it (wrong output), or crashes. In none of these cases does the function also decide what to do next based on its wrong answer.

An AI agent that hallucinates doesn’t just produce wrong output — it produces a wrong internal model of the world, and then plans and executes against that wrong model. The hallucination isn’t just an output artifact; it’s the premise for subsequent actions. If the agent incorrectly believes it’s operating in the staging environment (when it’s actually in prod), every correct action it takes against that false belief is destructive.

There’s also a confidence symmetry problem that has no analogue in traditional software. A function that returns a wrong value typically doesn’t also assert that it’s confident in the result. LLMs produce outputs with uniform fluency and apparent certainty regardless of whether they’re correct or hallucinating. There’s no native hesitation signal, no error state, no stack trace. The model that correctly identifies the database schema looks and sounds identical to the model that’s confabulating one.

This is compounded by what you might call hallucination in chain: in a multi-step agentic workflow, a hallucinated premise in step 2 propagates as ground truth into step 3, 4, and 5. Each subsequent step is locally coherent — the agent is reasoning correctly from its (wrong) premises. By the time the damage is done, the chain of reasoning looks internally consistent and intentional. There’s no obvious point of failure to trace back to; the entire workflow ran “correctly” against a false model of the world.

The final structural issue is irreversibility asymmetry. Hallucination in a chatbot produces wrong text — you read it, notice it’s wrong, discard it. The cost is negligible. Hallucination in an agent that has write access to infrastructure produces wrong actions, and those actions may not be reversible. The asymmetry between the cost of the mistake and the ability to recover from it grows dramatically as agents gain more capability. The same model behavior that’s a minor nuisance in a Q&A context is catastrophic in an agentic one.

3. Prompt Injection: Traditional threat: attacker needs access → privilege escalation → executes payload.

AI agent threat: the agent already has access, and it makes judgment calls. Prompt injection, hallucination, or misconfiguration simply redirects its existing permissions toward destruction.

Prompt injection exploits an architectural property of how LLMs process language — one that can be mitigated but not patched away. LLMs process both trusted system instructions and untrusted user inputs as identical text sequences. The model receives system prompts, conversation history, user input, and retrieved documents as a single continuous stream of tokens. You cannot parameterize natural language, so there’s no structural separation to tell the model which instructions to trust.

What to do?

The design or architecture flaws are really unfixable in LLMs at individual level right? So what now? Here are some things you need to figure out before giving AI full access- BACKUP AND ROLLBACK is the gist For businesses:

1. DO NOT BELIEVE VENDOR PROMISES THAT YOU CAN’T VERIFY (why am I shouting because this needs to register in everyone’s head) If someone says that they have implemented guardrails, ask them how were these created and tested. A lot of times people believe it’s a big corp like Google, Microsoft and Palo Alto so whatever they say must be right. Not true, anyone and everyone can make mistakes so verify before you trust. Everything may be nice 99.9% of the time but the 0.01% can really cause damage. Check for benchmarks, red-team reports, user reviews etc during vendor eval. If your business is small/medium sized, just have someone from IT/Dev go through a vendor’s trust portal and verify industry certifications and if it’s a startup ask for pentest reports, backup plans etc.

2.Principle of Least Privilege Every token, credential, or API key an AI agent can access must be scoped to exactly what it needs. The Cursor agent found an API token in an unrelated file whose permissions were far broader than the task required. Railway’s API allowed destructive actions without any confirmation check. This is a configuration problem that exists regardless of AI — AI just executes it faster. TechRadar

• Scope all tokens to specific actions, not resource-level access
• Use separate credentials for read vs. write vs. destructive operations
• Rotate and audit tokens agents can reach
• Store the creds in a vault or secrets manager.

3. Backups That Agents Can’t Reach The PocketOS disaster was compounded because Railway stored backups on the same volume as data. This is also an S3/cloud bucket misconfiguration pattern: if your agent has credentials that can write to prod, check whether those same credentials can delete the backup.

• Offsite, immutable backups (S3 Object Lock, Azure Immutable Blob Storage)
• Cross-region replication that is write-only from prod — no delete rights/soft delete
• Determine criticality of the apps etc and establish BC/DR Plan. It will help no matter how inconvenient.

1. Human-in-the-Loop for Important Actions Deleting anything? Take user consent. Overwriting an old file? Take user consent. Approving a big transaction? Take user constent. You get it right? Basically the human will review everything and take accountability of the agent/workflow they created. Capabilities cover every tool added, every Skill installed. The discipline of allowlists that’s the key. Pinning MCP server versions so they don’t silently update to a poisoned release, and reviewing which skill may actually be necessary.

• Never give agents write/delete access to prod in automated flows without a human approval gate
• Use normal mode instead of auto-approve modes. Annoying but not costly.
• For irreversible operations (volume deletion, mass email, financial transfers), require explicit confirmation with a description of what will be destroyed. If it’s that important, take approval twice.

5. MCP Server Hygiene

• Hundreds of MCP servers on the web are misconfigured, unnecessarily exposing users to cyberattacks. Around 7,000 MCP servers are open on the web, approximately half the total. Thus, only connect MCP servers you’ve reviewed. Pin versions. Don’t use archived/unmaintained servers.
• Treat third-party MCP servers like third-party npm packages.
• Create MCP Registry for allowing approved servers that way each new version and each new servers needs to be validated. Use InvariantLabs/Snyk’s Agent scan to detect issues and vulnerabilities.

6. AI Governance Before Deployment Before deploying agents into production workflows, document: what can this agent access, what’s the blast radius if it acts incorrectly, and who reviews its actions. Have a dedicated team (can be one person for small companies) to review the workflows, review compliance, cross-check safety controls before prod deployment. For small or similar usecases, you may automate some scans etc but still human review is important because LLM can’t come out of the screen and smack the developer for not following guidelines. PS: Workplace violence is wrong, beat them out side the campus where there are no camera./s

6. Monitoring and Audit Trails Agents should log every action they take — every API call, every file write, every tool invocation. Without this you can’t reconstruct what happened or demonstrate compliance. This is the foundation. Use ELK Stack and OpenTelemetry for performance benchmarks etc.

For Individuals / Personal Users: 1. Never run AI agents with admin/root Don’t give coding agents or MCP tools elevated OS permissions. Run them as a limited user. If an agent needs to install something, it should ask you — not execute as root.

2. Version control everything you care about If you’re using AI to edit code, documents, or configuration files, those files should be in git (or at minimum, have Time Machine / VSS snapshots on). An AI that refactors your codebase incorrectly is recoverable if you have a commit history. Without it, you have whatever the agent left behind.

3. Treat AI-suggested commands with the same skepticism as Stack Overflow answers A model that confidently tells you to run rm -rf node_modules && npm install is not wrong — until it autocompletes a broader path due to a hallucination or context confusion. Review destructive commands before executing them.

4. Don’t paste credentials into AI chat windows Even if you trust the model, MCP servers, browser extensions, and third-party tools in the pipeline may log or leak context. Hundreds of misconfigured MCP servers have been found exposing AI models to remote code execution and other cyberattacks, acting as bridges between AI tools and private data.

5. Compartmentalize what AI can touch Don’t give your AI assistant access to your email, calendar, GitHub, and cloud storage simultaneously unless you understand the full chain. Each integration multiplies what can go wrong.

6. Backup your Data Use OneDrive, ProtonDrive, pCloud etc so that you can get back important data. Easiest and most convenient way. Use USBs, hard disks or NAS for a offline copy of very important data like dissertation, research, lawyer files etc.

Prerequisites before we can start setting up

Setting up WSL (Windows 10/11)

Windows Subsystem for Linux(WSL) is a component of Microsoft Windows that allows the use of a Linux environment from within Windows without using a VM or dual booting. There are 2 versions- WSL 1 and 2. Both are very different from each other. You can check out their Wikipedia for more details. In this setup, I’m using WSL 2 which is a default in the recent versions of Windows (post 2019). WSL 2 uses a Linux kernel– a managed virtual machine via Hyper-V that implements the full Linux kernel. As a result, WSL 2 is compatible with more Linux binaries.

• Open a new PowerShell terminal as an admin and run the below command.

  wsl –install
  For a specific default distro: wsl –install –d < name>

This will enable WSL2 and install the default distro- Ubuntu which works well for this tutorial but you may go with other distros as well. If you’re facing issues, you can checkout this link. You may have to enable certain settings.

• Set up the username and password for the distro. PS- Don’t use the default credentials like admin/admin as it’s widely available in user manuals/guides and people are aware of it thus making it more vulnerable.

Install VS Code and Docker Desktop

It’s very simple. Just download from the official sources and run the GUI installer. VSCode is the IDE we’re using and Docker Desktop basically is an app that allows users to create, run, update and use docker containers. It let’s us interact with the image repos, local images, volumes etc. For Docker Desktop, remember to check the option to start docker at startup, unless you want to explicitly start the docker service every time manually.

Also, for simplicity sake, we will be using Docker Desktop. In the future, you may want to install Docker directly on your linux distro if the need arises.

Enable plugins on VS Code

On VS Code enable the plugins:

• Remote Development- WSL This plugin lets us use VS Code to build Linux applications that run on the Windows Subsystem for Linux (WSL)
• Remote Development- Dev Containers The extension lets us use a Docker container as a full-featured development environment.
• Docker The Docker Extension Pack makes it easy to build, manage, and deploy containerized applications from Visual Studio Code.

Configuring and setting up the container

Now that we’re done with the prerequsites open a new WSL window by clicking the blue button at the bottom left side corner and choose the first option- New WSL Window. PS- I have already set up the connection hence it shows as Connect to WSL but if it’s the first time you’re setting it up it should show as New WSL Window

From here onwards we’ll be working on Linux. We want to create a folder to store our project in the WSL Filesystem. In this case, I have created it in the home directory. Run this in your terminal to create the a new directory (mkdir name) and open the directory (cd name) in the terminal.

mkdir dev-container-test && cd dev-container-test

I’m manually creating the necessary files to configure the container but you can also use templates by going to the Command Palette and selecting the “Add Dev Container Configuration Files” option.

Create a new directory with the name .devcontainer with the . and under this directory create devcontainer.json , Dockerfile and requirements.txt files.

Now let’s update the files we just created!

devcontainer.json

This file tells VSCode how to build our ebvironment. Open devcontainer.json and paste this code:

{
  // This gives the dev container a name and let's the machine know to
  // build the container following the Dockerfile instructions.
  "name": "dev-container-test",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "customizations": {
    // Configure properties specific to VS Code.
    "vscode": {
      // Add extensions you want installed when the container is created.
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance"
      ]
    }
  },
  // All ports listed here will also be available outside your development
  // container i.e. in your machine’s localhost. By default, Docker
  // encapsulates your application in a box with no contact to the outside
  // world.
  "forwardPorts": [5000]
}

Dockerfile:

I’m going to use the container as a virtual development environment. So I want to write a Dockerfile to build a container image, beginning with the version of Python that I want, and then add all of my dependencies into it. Open Docker file and paste the below code:

    #The base image for the container that I have taken from DockerHub (it is hardened and secure to some extent already) 
    FROM python:3.11-slim
    
    # Disable buffering for Python's standard output (stdout) and standard error (stderr) streams so that output from Python app, such as Django logs, is sent directly to the container's logs in real time.      
    ENV PYTHONUNBUFFERED=1  
     
    # Copy python requirements to the docker container and install. Here we're going to install all our libraries and depndencies. 
    
    COPY requirements.txt .
    
    RUN python -m pip install -r requirements.txt

Requirements

In this file we’ll mention all the dependencies that needs to be downloaded and their versions (optional). Keeping this very simple with only Pylint which checks for programming errors, style issues, and potential bugs

pylint

Now we should be good to build and run the docker container. Open the command palette and choose “Dev Containers: Reopen in Container”. (If you have already built a container, choose “Rebuilt and Reopen in Container” instead.)

Once the container build is over it will open a new workspace where you can start your development. At any point, you can update your config and rebuild the container.
Happy Coding!

Microsoft has released a couple of AI-based features/functionalities in Windows 11 and 10. Currently, it is available as “Preview” with limited capabilities in select regions. Some more context about Copilot for those who are not aware about it:

What is Windows Co-pilot?

Let’s understand this first with some history. Microsoft is one of the major shareholder in OpenAI- the creator of ChatGPT models. Post the fame of LLM, chatbots and Gen-AI, Microsoft decided to set up it’s own GPT instances and infuse AI in some of it’s functionalities and products like in Bing Search or in Quick Search. It let’s you give text based commands like turn on dark mode or search for flight details etc.

Why you should disable Co-pilot?

There is one big reason, you may want to not use these products, till countries/governments release some laws to protect individual rights and IP (intellectual property) and that is PRIVACY. According to Microsoft’s Terms of Service and Privacy Policy, it not only captures your data but also may sell it to third-parties or use it for development of their services.

Use of Your Content. As part of providing the AI services, Microsoft will process and store your inputs to the service as well as output from the service, for purposes of monitoring for and preventing abusive or harmful uses or outputs of the service. ~ Terms of Service under AI services (iv)

Privacy Policy is a bit long because it covers all products under Micrsoft but TL;DR or key points can be found here

If you do have time, I would recommend going through atleast the AI section (Search, Microsoft Edge, and artificial intelligence) since Microsoft is coming up with new AI features.

Why does it matter that some data they may collect?

A lot of people believe their information is not that important enough because they may not be famous or may not have anything to hide so it’s not an issue if any company accesses their data. But it matters and some day-to day examples of why:

• your data is used by companies usually to market their product in a way that it appeals to you. Instead of ensuring quality and good products, it’s more about trying to trying to generate sales and profit. They may also sell the different types of data from your devices, networks and devices to other companies leading to exploitation. Some Facebook/Meta related examples:

  • Recently, court documents were unsealed as part of a major anti-trust lawsuit filed in U.S. claim Netflix and Facebook “enjoyed a special relationship” so that Netflix could better tailor its ads with Facebook involving millions of dollars.
  • In 2018, the New York Times published a report citing hundreds of pages of Facebook documents, alleging Facebook had authorized Spotify and Netflix to access users’ DMs. PS: Microsoft did say they may sell/share your data with third-parties.

• in some AI apps, such as self-driving cars, have the ability to track your location and driving habits to help the car understand its surroundings and act accordingly. While this technology may help make cars safer and smarter, it also opens more opportunities for your personal information to become part of a larger data set that can be tracked across different devices in your home, work, or public spaces.

• your images (even just a selfie in which you’re fully clothed) may be used to generate porn or for revenge porn without your knowledge or permission.

• data scraped from the internet using tools may memorize personal information about people, as well as relational data about their family and friends. This data helps enable spear-phishing—the deliberate targeting of people for purposes of identity theft or fraud. Already, bad actors are using AI voice cloning to impersonate people and then extort them over good old-fashioned phones.

How do I disable Co-pilot?

I would have to admit, Microsoft has not made this easy with not providing an option to opt-out of this preview or even by not being transparent regarding removal options. Also, enabling features that collect personal data in an update without letting users explicitly know about the same. But fortunately, the steps to follow are easy:

• Remove it from the Taskbar (doesn’t remove Copilot completely) Go to Setting -> Personalization -> Taskbar -> Toggle of Copilot

2. Use Registry Editor to disable it for all users (again doesn’t disable Copilot completely, it will still run as background process)

   • Go to Registry Editor
   • Using Ctrl + F find the TurnOffWindowsCopilot section.
   • We need to update the REG_DWORD from 0 to 1 to run this function. To do that you can either manually change the values or create a text file and add this code from Shawn Brink:

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\WindowsCopilot]
"TurnOffWindowsCopilot"=dword:0000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsCopilot]
"TurnOffWindowsCopilot"=dword:0000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"HubsSidebarEnabled"=dword:0000001

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer]
"DisableSearchBoxSuggestions"=dword:0000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer]
"DisableSearchBoxSuggestions"=dword:0000001

What does this code do ? Well essentially we’re updating the configuration information that the OS has. The HKEY_CURRENT_USER (HKCU) registry hive stores configuration information specific to the current/logged-in user. The HKEY_LOCAL_MACHINE (HKLM) registry hive holds most of the configuration data for Windows OS itself and it’s software.

3. Finally, we can use gedit or Group Policy Editor to remove the Co-Pilot Bundle. This completely removes Co-Pilot from your system.
   • Search gedit or run gedit.msc file to open Group Policy Editor.
   • Follow the path: User Configuration > Administrative Templates > Windows Components > Windows Copilot
   • In the Windows Copilot folder, double click Turn Off Windows Copilot. In the pop-up, choose the Enabled button and apply the changes.

References:

1. https://www.elevenforum.com/t/completely-disable-and-remove-copilot-in-windows-11.23264/
2. https://www.laptopmag.com/software/how-to-turn-off-copilot-in-windows-11-keep-it-ai-free
3. https://www.tomsguide.com/computing/software/how-disable-copilot-in-windows-11

PS: Somethings are already covered in my previous post (Arch installation guide), I’ll add a * to those items

General Edition:

• Sorting the mirrors*- follow the instructions to re-order your mirrors by fastest speed. I have used Reflector.
• Install Sound system and Display Server (Xorg or Wayland)*
• Set up Window manager or Desktop environment like GNOME, Plasma, Xfce etc*
• Create user directory files

sudo pacman -S xdg-user-dirs

xdg-user-dirs-update

• Configure Pacman Using the below command, you can open the pacman configuration file and uncomment the necessary lines: -allow ParallelDownloads under [options] -add colors -enable VerbosePkgLists to view name, version and size of target packages formatted -CleanMethod = KeepCurrent under[options] to clean up the cache so that only outdated tarballs are deleted -NoExtract (Guidelines with examples)

sudo nano /etc/pacman.conf

• Set up paccache to clean package cache

sudo pacman -S pacman-contrib
#activate the paccache timer:
sudo systemctl enable paccache.timer

You can automate the process by creating a hook using package paccache-hook under path /etc/pacman.d/hooks/ with a .hook file (eg: remove_old_cache.hook) Sample script

[Trigger]
Operation = Remove
Operation = Install
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Keep the last cache and the currently installed.
When = PostTransaction
Exec = /usr/bin/paccache -rvk2

• Install essential packages:

sudo pacman -S --needed firefox nemo leafpad evince ksnip lximage-qt libreoffice-fresh vlc

• Setting up an AUR helper like yay, pacaur, paru etc: AUR helpers automate usage of the Arch User Repository.

sudo pacman -S --needed base-devel git
mkdir Programs
cd Programs
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

Security Edition:

• Creating a non-root user with sudo permissions* A new installation leaves you with only the superuser account, better known as “root”. Logging in as root for prolonged periods of time, possibly even exposing it via SSH on a server, is insecure. Instead, you should create and use unprivileged user account(s) for most tasks, only using the root account for system administration. How to do that? Add a user and set a password. Add them to the wheel group and use visudo command to edit the sudoers file. Uncomment the command that allows members of wheel group to use sudo.

• Set up password managers and install libpwquality Note: Desktop environments have their own password managers apps available as part of the package.

• Install the microcode* Processor manufacturers release stability and security updates to the processor microcode. These updates provide bug fixes that can be critical to the stability of your system. Without them, you may experience spurious crashes or unexpected system halts that can be difficult to track down.

#for AMD:
sudo pacman -S amd-ucode

#for Intel:
sudo pacman -Sy intel-ucode 

#Check the kernel messages with _journalctl_ to see if the microcode has been updated:
journalctl -k --grep='microcode:'

#One should see something similar to the following on every boot, indicating that microcode is updated very early on:
#kernel: microcode: Current revision: 0x00000012
#kernel: microcode: Updated early from: 0x0000000e

• Enforce a delay after a failed login attempt

Add the following line to /etc/pam.d/system-login to add a delay of at least 4 seconds between failed login attempts:

auth optional pam_faildelay.so delay=4000000
#`4000000` is the time in microseconds to delay.

• Restricting root login Once sudo is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use sudo, you can use

passwd --lock root

• Configure SSH SSH is a protocol used to securely log onto remote systems. Modifying the SSH daemon configuration file, typically found at ‘/etc/ssh/sshd_config’ to customize the configs:

# Disable root login 
PermitRootLogin no 

# Enable public key authentication 
PubkeyAuthentication yes  

# Specify the allowed users (add your sudo user in place of user1 and user 2)
AllowUsers user1 user2 

# Change the default port 
Port 2222 

# Limit the number of authentication attempts 
MaxAuthTries 3
 
# Enable two-factor authentication
AuthenticationMethods publickey,password 
publickey,keyboard-interactive

After making these changes, don’t forget to restart the SSH service for the changes to take effect.

• Configure firewall. By default firewall is not enabled on Arch. You can configure firewall rules via iptables and nftables and implement them. UFW (Uncomplicated Firewall) can also be used. It is a program for managing a netfilter firewall. It provides a command line interface and aims to be uncomplicated and easy to use.

#Install UFW:
sudo pacman -S ufw

#Enable UFW:
sudo ufw enable

#Check its status:
sudo ufw status numbered

The default settings are good enough for most users.

• Setup backups To be able to restore your machine and data back to it’s original state in case of any errors or issues is important.

Pre-requisites to create a backup: external hard drive or server for storing your backup. You can get cloud storage via rsync.net, koofr or BorgBase.

For backup I recommend and use Borg which is opensource and supports a lot of features like compression, duplicity etc. It also has a GUI interface Vorta.

#For Vorta:
yay -S vorta 
# FYI- Maintained by https://github.com/bjo81 

#For Borg CLI:
sudo pacman -S borg

• For Vorta, checkout- this video by Sun Knudsen or this step-by-step tutorial by Karthick from OSTechNix

• For Borg CLI, checkout the official guide or tutorial by Karthick from OSTechNix

Installation Methods

We can set up Arch Linux:

1. With a guided installer like archinstall (tried by me) The installer is released as a part of the official ISO images since 2021. This is a python library can be downloaded via pip or ran using git. Other guided installers: archfi, and Anarchy

2. Without the guided installer This is the default installation method and requires you to manually configure all the components as per the official guide.

Arch Modes

As I understand, based on the firmware and disk partitioning - Master Boot Record (partition table) and GUID Partition Table, we have different modes to set up Arch. Here’s a quick overview below:

1. Legacy/BIOS Mode

• BIOS is short for Basic Input-Output system. It’s low-level software that resides in a chip on your computer’s motherboard.
• The BIOS loads when your computer starts up. The BIOS goes through a POST, or Power-On Self Test, before booting your operating system. It checks to ensure your hardware configuration is valid and working properly. If something is wrong, you’ll see an error message or hear a cryptic series of beep codes. When your computer boots—and after the POST finishes—the BIOS looks for a Master Boot Record or MBR, stored on the boot device and uses it to launch the bootloader TLDR; BIOS is responsible for waking up your computer’s hardware components, ensures they’re functioning properly, and then runs the bootloader that boots Windows or whatever other operating system you have installed.
• The traditional BIOS still has serious limitations. It can only boot from drives of 2.1 TB or less. 8 TB drives are now common, and a computer with a BIOS can’t boot from them. That limitation is due to the way the BIOS’s Master Boot Record system works.The BIOS must run in 16-bit processor mode, and only has 1 MB of space to execute in. It has trouble initializing multiple hardware devices at once, which leads to a slower boot process when initializing all the hardware interfaces and devices on a modern PC.

2. UEFI Mode

• The Unified Extensible Firmware Interface (UEFI, successor of the EFI) is an interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications. Developed in 2007, UEFI replaces the traditional BIOS on PCs.
• This new standard avoids the limitations of the BIOS. The UEFI firmware can boot from drives of 2.2TB or larger—in fact, the theoretical limit is 9.4 zettabytes. UEFI uses the GPT partitioning scheme instead of MBR. It also boots in a more standardized way, launching EFI executables rather than running code from a drive’s master boot record.
• UEFI can run in 32-bit or 64-bit mode and has more addressable address space than BIOS, which means your boot process is faster.
• UEFI is packed with other features. It supports Secure Boot, which means the operating system can be checked for validity to ensure no malware has tampered with the boot process. It can support networking features right in the UEFI firmware itself, which can aid in remote troubleshooting and configuration. With a traditional BIOS, you have to be sitting in front of a physical computer to configure it.
• Check this out if you want to know the specifics regarding UEFI mode in Linux: https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/

Note: The official installation image does not support Secure Boot (FS#53864). Secure Boot support was initially added in archlinux-2013.07.01-dual.iso and later removed in archlinux-2016.06.01-dual.iso. At that time prebootloader was replaced with efitools, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since. In order to boot an installation medium in a Secure Boot system, you will need to either disable Secure Boot or modify the image in order to add a signed boot loader. Archboot images provide a way to use secure boot on installation media.

In this article, I’ll go over the setting up Arch Linux without the guided installer on Virtual Box.

FYI- I’m setting Arch on a VirtualBox VM in UEFI mode with GUID Partition Table (GPT) partition. I will add details regarding setting up for BIOS/legacy mode and MBR partition details but may not have the screenshots.

If you’re setting it up on your machine:

• Please create a live USB of Arch Linux to set up and then follow the guide from #6.
• Disable Secure Boot or modify the official ISO image accordingly.

Pre- Installation Steps

1. Download and setup VirtualBox from the official site
2. Download the official ISO image and the ISO PGP signature from Arch Linux official site
3. Before the installation we’ll verify the acquired ISO image using GnuPG. Digital signatures are used to ensure that you get an exact copy from the original packager and not a malicious version from a compromised site. OpenPGP programs such as GPG/GnuPG are used to sign and verify those packages.

gpg --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig

Substitute ‘archlinux-version-x86_64.iso.sig’ with the name of the ISO PGP Signature file.

The output should have Good Signature mentioned similar to the below screenshot:

4. Create the VM on VirtualBox with the below specifications:

• Create a new machine and name it Arch Linux.
• Specify the path to the downloaded Arch Linux ISO.
• Choose base memory as 1024 MB (default)
• Assign 1GB of RAM (default). If you have the RAM, you can allocate 2GB.
• Enable the UEFI mode.
• Create a virtual hadisk (VDI) and allocate20GB.
• Click Create.

5. Click start to run the VM and press enter to choose Arch Linux Install Medium (x86_64, x64 UEFI). This is the first option. If you’re setting up Arch in legacy/BIOS mode, it should show as Arch Linux Install Medium (x86_64, x64 BIOS)

6. For enabling/setting up the internet. If you use a wired connection, it is usually picked up automatically. As I’m setting it up on a VM, it was picked u automatically. To check connection to the internet, we’ll use ping command:

ping -c 3 google.com

Wi-Fi requires some additional settings. For Wi-Fi, we’ll use iwctl:

iwctl
 ...
Output:
#iwctl
[iwd]#

Command to get your system’s wireless device name

[iwd]# device list 
...
Output:
[iwd]# device list 
#You should see something like this: 
            Devices  
--------------------------------------------
 Name   Address   Powered    Adapter   Mode  
-------------------------------------------- 
wlan0   ...        on         ...      ...

To get the list of WiFi networks, run the below command. Replace wlan0 with your device name on the below command and all the following commands.

station wlan0 get-networks 
...
Output:
[iwd]# station wlan0 get-networks  
#You should see something like this: 
           Available Networks  
--------------------------------------------
 Network Name       Security       Signal  
-------------------------------------------- 
  TP-Link_8DAB      psk            *****
  dlink             wep            *****

To connect to the WiFi network, run the below command with the WiFi access point name from the above “get-networks” command. Enter your WiFi password when prompted.

station wlan0 connect
...
Output:
[iwd]# station wlan0 connect
#You should see something like this: 
Type the network passprahase for TP-Link_8DAB psk.
Passphrase: *******

Exit the iwctl using exit or Ctrl+C and test the connection again using ping command.

8. Now moving to Partitions! For partitioning the disks, we’ll use command line based partition manager- fdisk

• When recognized by the live system, disks are assigned to a block device such as /dev/sda, /dev/nvme0n1 or /dev/mmcblk0. To identify these devices, use lsblk or fdisk.

fdisk -l

Results ending in rom, loop or airootfs may be ignored. mmcblk* devices ending in rpbm, boot0 and boot1 can be ignored.

• Check if you have UEFI mode enabled using this command:

ls /sys/firmware/efi/efivars

If this directory exists, you have a UEFI enabled system. You should follow the steps for UEFI system.

• If you already have a partition table, skip this step. If your hard drive is brand-new as in the case of a virtual machine or you want to re-partition your hard drive, run this command to create a new partition table:

cfdisk /dev/sda

Steps to follow for UEFI with GPT: In the label type window, select GPT. ss for gpt Example layout for 20 GB Disk Size which I’m following

Use the arrow keys and enter to create 3 partitions with cfdisk:

• /dev/sda1 # choose 512Mb of space (UEFI)
• /dev/sda2 # choose at least 10 GB of space (root)
• /dev/sda3 # choose all the left space (home)

Write the table to your hard drive and quit.

Steps to follow for BIOS with MBR: Example layouts for 20 GB Disk Size.

If you do the legacy installation, skip the step of UEFI formatting because you should not have the UEFI partition. Use the arrow keys and enter to create 2 partitions with cfdisk:

• /dev/sda1 # choose at least 10 GB of space (root)
• /dev/sda2 # choose all the left space (home)

Write the table to your hard drive and quit.

Mount the partitions:

#For UEFI partition:
mkfs.fat -F32 /dev/sda1

#For non-UEFI partitions:
mkfs.ext4 /dev/sda2

#For Swap partition
mkswap /dev/sda3

9. Mount the filesystems:

#Mount the root volume to  `/mnt`:
mount /dev/sda2 /mnt

#For UEFI systems, create new dir /mnt/boot and mount the EFI system partition:
mount --mkdir /dev/sda1 /mnt/boot

#For Swap volume,
swapon /dev/sda3 

10. Configuring Reflectors

Packages to be installed must be downloaded from mirror servers, which are defined in /etc/pacman.d/mirrorlist. On the live system, after connecting to the internet, reflector updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate. The top mirror is chosen automatically and it may not always be a good choice. Let’s update to ensure we have good mirror list available.

# Install reflector to update the list of fastest mirrors located in your country:
pacman -Sy reflector

#Make a backup of mirror list (just in case):
cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak

#Get the mirror list and save it
reflector -c "India" -f 12 -l 10 -n 12 --save /etc/pacman.d/mirrorlist

Woohoo! We’re done with all the pre-installation steps :)

Installation Steps

Using the pacstrap script we’ll install the base package, Linux kernel and firmware for common hardware. I’m also adding nano editor (you can use vim or anyother editor) and sudo (short for super user do)

pacstrap -i /mnt base linux linux-firmware sudo nano

Let’s move to configuring the system!

Configure the system

1. Generate the fstab file

The fstab file can be used to define how disk partitions, various other block devices, or remote file systems should be mounted into the file system. You can type genfstab -help to see the options available and it’s description.

One can use genfstab to generate fstab entries for mounted partitions given a filesystem root. This can be useful when installing and that’s what we’ll do.

There are different ways to identify file systems that will be mounted in /etc/fstab: kernel name descriptor, file system label and UUID, and GPT partition label and UUID for GPT disks. Kernel name descriptors should not be used, while UUIDs or PARTUUIDs should be preferred over labels because:

• Labels have to be unambiguous to prevent any possible conflicts.
• Labels can be up to 16 characters long.
• Since the label is a property of the filesystem, it is not suitable for addressing a single RAID device persistently.

Thus, we’ll generate an fstab file using UUIDs as identifiers. We’ll use -U which specifies that you want to generate the output based on a volume UUID.
So genfstab -U /mnt will output all current mounts under the /mnt mount point. We can save that output to the /mnt/etc/fstab file using the >> operator.

genfstab -U /mnt >> /mnt/etc/fstab

2. chroot (change root) to the installed system Changing root is commonly done for performing system maintenance on systems where booting and/or logging in is no longer possible. Common examples are:

• Reinstalling the boot loader.
• Rebuilding the initramfs image.
• Upgrading or downgrading packages.
• Resetting a forgotten password.
• Building packages in a clean chroot.

Now using arch-chroot we’ll enter the mounted disk as root.

# arch-chroot /mnt

3. Set locale To set the localization, you will have to work in nano editor.
   Run command to open file in the editor:

nano /etc/locale.gen

In the file find the language you are going to use and uncomment it by removing #. In my case, I am going to install English (en_US.UTF-8 UTF-8).

You can either manually do it or activate the search option using the shortcut Ctrl + W. Press Ctrl+O Enter to save and Ctrl+X Enter to exit the editor.

Run command to generate the locale:

locale-gen

Finally, Create the locale.conf file, and set the LANG variable accordingly:

echo "LANG=en_US.UTF-8" > /etc/locale.conf

4. Set the time zone by creating a symbolic link A symbolic link, also known as a symlink or soft link, is a special type of file that points to another file or directory. Symbolic links are commonly used to create shortcuts or aliases for files or directories located in the file system.

# Run command to get details about all the zones:
ls /usr/share/zoneinfo/

#Run command to create the link:
 ln -sf /usr/share/zoneinfo/Asia/Calcutta/etc/localtime
 
# Run hwclock to set the local time on the system:
hwclock --systohc --utc

5. Set hostname

Hostname is basically the name of your computer on the network. I’m name it arch but you can choose whatever you want. Use the following command:

echo arch > /etc/hostname

Local host name resolution is provided by nss-myhostname (an NSS module provided by systemd) without having to edit /etc/hosts file. It is enabled by default.

But some software may still read the /etc/hosts file directly. So let’s edit /etc/hosts file in nano and add the following lines to it:

nano /etc/hosts

Add these lines at the end of the file:

127.0.0.1        localhost
::1              localhost
127.0.1.1        arch

If you use a static IP address, replace 127.0.1.1 with your static IP address given by the Internet provider. Press Ctrl+O Enter and Ctrl+X Enter to save and exit the editor.

6. Configure the network We’ll use NetworkManager package: NetworkManager is a network management tool that provides easy automatic connection to the Internet. NetworkManager manages your network interfaces, detects available connections and automatically connects network devices when connections for the device become available. In practice, NM provides “set it and forget it” functionality—after connecting to a network on a given network interface, NM remembers the connection and will automatically connect you in the future (unless you disable automatic connection, of course). The networkmanager package contains a few things: the NetworkManager daemon itself, the nmcli command line interface, and the nmtui and a text user interface. To install the package, we’ll use the package manager pacman:

pacman -S networkmanager

Since Automatic network configuration is accomplished using Dynamic Host Configuration Protocol (DHCP). The network’s DHCP server provides IP address(es), the default gateway IP address(es) and optionally also DNS name servers upon request from the DHCP client. We’ll use systemd-resolved for DNS resolution which NetworkManager can then use for DNS resolution, i.e. converting human-readable domain names into computer-friendly IP addresses.

# Check service status
systemctl status systemd-resolved.service

# If the service is not active and running, enable and start it
systemctl enable --now systemd-resolved.service

• For wired internet connection, Enable NM using :

systemctl enable NetworkManager

• For WiFi connection: First enable Wi-Fi and list available wireless networks:

# Ensure Wi-Fi is enabled
nmcli radio wifi
...
Output:
nmcli radio wifi on

# List available Wi-Fi networks
 nmcli device wifi list
...
Output:
BSSID              SSID            MODE   CHAN  RATE        SIGNAL  BARS  SECURITY
AA:11:BB:22:CC:33  MyCoolNetwork   Infra  6     230 Mbit/s  95      ▂▄▆_  WPA2
DD:44:EE:55:FF:66  AnotherNetork   Infra  6     195 Mbit/s  90      ▂▄▆_  WPA1 WPA2
GG:77:HH:88:II:99  FooBarNetwork   Infra  6     175 Mbit/s  85      ▂▄▆_  --

Identify your desired network’s SSID, and connect as follows:

# Specify network SSID and password (for secured networks)
nmcli device wifi connect {SSID} password [password]
...
Output:
#Secured Network
nmcli device wifi connect 'MyCoolNetwork' password 'my_secure_password'

# Unsecured networks don't need a password
nmcli device wifi connect 'FooBarNetwork'

7. Set the password for root user The passwd command lets you change the password for a user. By default it affects the current user’s password which is the root right now.

passwd

You’ll have to type the password twice. It will not show when you’re typing, not even as *****

8. Add a non-root user: Using your Linux system as the root user for long is not a good idea so creating a non-root user is important. To create a new user, execute the following command:

useradd -m -G wheel bhavs

The useradd command lets you create a new user. -m option indicates that you also want it to create the corresponding home directory. The -G option will add the new user to the wheel group which is the administration user group in Arch Linux.

Now you can use the passwd command once again to set the password for the newly created user:

passwd bhavs

Finally, you’ll have to enable sudo privilege for this new user. To do so, open the /etc/sudoers file using nano. Once open, locate the following line and uncomment it:

# %wheel ALL=(ALL) ALL

This file essentially means that all users in the wheel group can use sudo by providing their password. Save the file by hitting Ctrl + O and exit nano by hitting Ctrl + X. Now the new user will be able to use sudo when necessary.

9. Installing the microcode: Processor manufacturers release stability and security updates to the processor microcode. These updates provide bug fixes that can be critical to the stability of your system. Without them, you may experience spurious crashes or unexpected system halts that can be difficult to track down.

PS- In virtual machines and containers, the microcode updates belongs on the host, not in the guest system.

To acquire updated microcode, depending on the processor, install one of the following packages:

• amd-ucode for AMD processors,
• intel-ucode for Intel processors

# for amd processors
pacman -S amd-ucode

# for intel processors
pacman -S intel-ucode

9. Install and configure the bootloader:

A boot loader is a piece of software started by the firmware (BIOS or UEFI). It is responsible for loading the kernel with the wanted kernel parameters and any external initramfs images. There are several bootloaders you can install on Arch Linux. I recommend the GRUB bootloader which is built-in and supports both UEFI and BIOS. It is the most popular, highly configurable and easy to use bootloader.

• For UEFI:

#Install the GRUB bootloader and EFI boot manager packages:
pacman -Sy grub efibootmgr

#  The mkdir command creates a directory called `efi` inside the `/boot` directory. After creating the directory, we'll  mount the EFI system partition in that directory:
mount --mkdir /dev/sda1 /boot/efi

# Check if everything is mounted correctly:
lsblk 

#Install GRUB in the newly mounted EFI system partition:
grub-install --target=x86_64-efi --bootloader-id=GRUB --efi-directory=/boot/efi --removable

#The grub-mkconfig command generates the GRUB configuration file and saves it to a given target location- /boot/grub/grub.cfg
grub-mkconfig -o /boot/grub/grub.cfg

• For BIOS:

#Install GRUB:
grub-install /dev/sda

#The grub-mkconfig command generates the GRUB configuration file and saves it to a given target location- /boot/grub/grub.cfg
grub-mkconfig -o /boot/grub/grub.cfg

10. Install Desktop Environment:

To run programs with graphical user interfaces on your system, you’ll have to install an X Window System implementation and Audio. The most common one is xorg. I’ve also added virtualbox-guest-utils since I’m setting up Arch on a VM.

pacman -Sy pulseaudio pulseaudio-alsa xorg xorg-xinit xorg-server virtualbox-guest-utils

Now that you’ve installed Xorg, you’re ready to install a desktop environment. Arch Linux supports a long list of desktop environments like GNOME, Plasma, XFCE etc. I’m installing GNOME in this guide.

# Install GNOME package
pacman -Sy gnome

#Enable the GDM or Gnome Display Manager service
systemctl enable gdm

12. Final Step: Reboot

#First come out of the Arch-Chroot environment:
exit

#Unmount the root partition to make sure there are no pending operations:
umount -R /mnt

#Reboot the machine:
reboot

Wait until you see the GRUB menu. Choose Arch Linux from the list and wait until the system finishes booting up.

Arch Linux (Minimal) Installation is done! Congratulations!! Reminder- This is a very minimal installation. From this point, you can install what you want and configure your Arch Linux as you want. If you have any queries, check out the Arch Linux forums.

Refrences:

• https://wiki.archlinux.org/title/Installation_guide#Installation
• https://www.freecodecamp.org/news/how-to-install-arch-linux/
• https://averagelinuxuser.com/a-step-by-step-arch-linux-installation-guide/#download-arch-linux-iso
• Arch Linux Wiki and Forums