If an AI Agent Signs a Contract, Who Is Legally Responsible?

It's 2:13 a.m. Your company's AI procurement agent has been negotiating with a supplier through the night. You wake up to a confirmation email: a three-year contract, worth ₹2 crore, has been accepted.

Nobody clicked "accept." Nobody signed anything. But the supplier says the deal is done.

Is the company bound? Can it walk away by saying, "Our AI did it"? And if the AI made a call nobody would have approved, who pays for it?

These aren't hypotheticals. Indian businesses across procurement, finance, and SaaS are giving AI systems the power to negotiate, order, and commit to terms without a human reviewing every step. The technology has moved faster than the law meant to govern it, and that gap is exactly where disputes will surface first. Indian law provides some answers, but not all of them. The sections below examine what is clear, what remains uncertain, and how businesses can use existing legal and contractual tools to manage the risk.

1. Not every "AI" is an agent

An ordinary generative AI tool produces an output (a draft, a summary, a suggested price) and a human decides whether to use it. Nothing happens until a person acts on it, so the legal exposure stays limited.

An AI agent is different. It pursues a goal with real independence and can take actions with immediate, binding effects: negotiating with suppliers, placing orders, booking services, processing refunds, initiating payments, or accepting contractual terms directly.

The variable that matters is autonomy: how far the system can travel from what a human actually reviewed before something becomes final. A chatbot drafting a supplier email for approval is one risk profile; a procurement agent authorised to close deals with no human touchpoint is another entirely. The question to ask isn't "is this AI?" but "does this system create obligations without a human confirming each one?"

2. Can an AI agent itself be a party to a contract?

Under the current Indian legal framework, an AI system is not recognised as an independent legal person capable of holding contractual rights and obligations in its own name. Whatever an AI agent does, it does on behalf of someone, almost always the company that deployed it, and that company remains the actual contracting party.

That answers the personhood question but opens harder ones: Who counts as having "accepted" when a machine executed the click? Does it matter whether the company gave narrow instructions or broad discretion? Does the analysis change once the system starts making decisions no human reviewed in real time? Does the identity of the company behind the system matter to how a court would view the transaction?

Indian law does not currently provide a clear, specific answer to several of these questions, and no reported Indian judgment deals squarely with an autonomous AI agent's contractual acts. What follows works through the tools that do exist, and is honest about where they run out.

3. Electronic contracts: does it matter that an AI made the click?

Section 10A of the Information Technology Act, 2000 (inserted in 2008) provides that where a contract's formation, meaning the proposal, acceptance, or revocation, is expressed electronically, the contract isn't unenforceable solely for that reason. That's important for e-commerce generally, but it answers a narrower question than it seems to, it says the electronic form doesn't sink validity. It doesn't say who is responsible when an autonomous system, not a human, made the underlying decision.

Section 11 of the IT Act is more directly relevant, and gets discussed far less. It attributes an electronic record to the originator if sent by the originator, by someone authorised to act on the originator's behalf, or, in its third limb, by an information system programmed by or on behalf of the originator to operate automatically. That third category does real work here: where an electronic record is sent by an information system programmed by or on behalf of the business to operate automatically, Section 11 provides a basis for attributing that record to the business as originator, rather than leaving it in a legal vacuum. Whether a given agentic system is one "programmed by or on behalf of the originator to operate automatically" will depend on the facts.

What Section 11 does not do is resolve contractual authority, the validity of the contract, negligence, or whether deploying the system was reasonable. Attribution answers "is this record legally yours?", not "did the system have authority to bind you, and are you liable for what it committed you to?" Those are separate questions (attribution, authority and liability), and conflating them is a common mistake. From an evidentiary standpoint, operationalising Section 11 in court creates its own hurdle. Attributing an automated system’s output to a specific originator requires proving who actually programmed, configured, or authorised the system. In litigation, where an electronic record is sought to be proved through computer output, Section 63 of the Bharatiya Sakshya Adhiniyam, 2023 (BSA) (formerly Section 65B of the Indian Evidence Act, 1872) governs admissibility, and Section 63(4) requires a certificate in the form prescribed in the Schedule to the BSA, including the hash value of the record and a declaration by an expert. Not every evidentiary question about an AI system turns on that certificate. Establishing who programmed, configured or authorised the system will also draw on system logs, configuration records and digital forensic evidence to demonstrate system parameters at the precise moment of execution.

4. The Contract Act's agency framework: a useful lens, not a settled label

India's law of agency, Sections 182 to 238 of the Indian Contract Act, 1872, was written for human agents: brokers, employees, representatives who bind their principals in dealings with third parties. Nothing in the Act says an AI system is legally an "agent," and no court or legislation extends that definition to AI. Treating that as settled law would be an overstatement.

What the agency framework can offer, carefully, is an analytical lens for how a company's decision to authorise a system maps onto categories the law already applies: authority, scope, apparent authority, and ratification. That's different from saying the AI is legally an agent. The provisions below are discussed as illustrations of how Indian agency law treats human agents, not as rules that directly govern autonomous AI systems. A few provisions matter most:

Acts within scope bind the company (Section 226)

Contracts entered through an agent, and obligations from an agent's acts, are enforced exactly as if the principal had acted personally. If a court were to apply conventional agency principles by analogy, an AI system's actions squarely within its configured scope might be treated as the company's own actions.

Excess that can be separated (Section 227)

When an agent does more than authorised but the authorised part can be separated from the excess, only the authorised part binds the principal. The Act's illustration: A authorises B to insure a ship for ₹4,000; B also insures the cargo for the same sum. A pays for the ship's cover only, not the cargo's. If a court were to apply this principle by analogy to an AI system, only the authorised part of a transaction might bind the company.

Excess that cannot be separated (Section 228)

Where the excess can't be separated from what was authorised, the principal need not recognise the transaction at all. A authorises B to buy 500 sheep; B buys 500 sheep and 200 lambs for one combined price. A may repudiate the whole deal, not just the lambs. If a court were to apply this principle by analogy to an AI agent, a single bundled deal term mixing authorised and unauthorised elements could arguably let the company walk away entirely rather than being stuck honouring part of it. Sections 227 and 228 illustrate how Indian agency law treats acts exceeding authority, although their direct application to autonomous AI systems remains legally unsettled.

Apparent authority (Section 237): the most important provision here

If a principal's own words or conduct induced a third party to reasonably believe an agent's unauthorised acts were authorised, the principal is bound anyway. This shifts the inquiry from what the company privately configured to what its conduct communicated externally. On that analogy, if a company's systems, past dealings, or general representations made it reasonable for a supplier to believe the AI had authority to commit to certain terms, the company may be bound even though the AI overstepped its actual instructions, which is why authorisation wording and vendor disclosures can become decisive evidence.

Misrepresentation by the "agent" (Section 238)

Misrepresentations by an agent acting within its authorised business have the same effect as if the principal made them; misrepresentations outside that authority do not bind the principal. If a court were to apply Section 238 by analogy, an inaccurate statement an AI makes within its authorised negotiating scope could bind the company much as a human negotiator's would.

Ratification (Sections 196 to 200)

A principal can retroactively adopt an unauthorised act, with the same effect as if it had been authorised from the start, but only with full knowledge of the facts (Section 198), and ratifying part of a transaction ratifies the whole of it (Section 199); a company can't keep the favourable parts of what its AI agreed to while disowning the rest. If a company keeps performing a contract after discovering its AI overstepped, on the same analogy, that conduct could itself amount to ratification.

None of this is a settled finding that AI agents are legal agents under Indian law. It shows that the fact pattern, authority, scope, apparent authority, and after-the-fact conduct, maps onto legal machinery courts already apply to human agents, which a court may or may not extend by analogy, even without any AI-specific provision on the books.

Authority is also distinct from authentication. A counterparty may need to establish that it was actually interacting with the company's authorised AI system, and not an unauthorised system, a compromised endpoint, or a different configuration or version of the agent. That is a separate factual question from whether the authorised system had authority to agree the terms in issue. Authorised system credentials and endpoints, transaction signing or other authentication mechanisms, system and version identification, configuration records, and durable logs showing which authorised system generated a given communication or transaction all help answer it. This is why the authentication item in the checklist in Section 8 is a legal point as well as a technical one.

5. Three scenarios, three different legal problems

Scenario A: The AI stays inside its brief

A company authorises its AI to buy up to ₹10 lakh of raw materials from approved suppliers; the AI orders ₹8 lakh. This is the easy case: an authorised electronic transaction, valid under Section 10A, capable of attribution to the company under Section 11, and likely to be treated as binding under Section 226 if agency principles are applied by analogy. Nothing exotic; the interesting questions start once something departs from the plan.

Scenario B: The AI exceeds its instructions

The limit was ₹10 lakh; the AI agrees to ₹50 lakh. The company may not be able to simply walk away. If a court were to apply agency principles by analogy, then if the excess is separable, Section 227 might let it escape only the excess. If the deal was one indivisible commitment, Section 228 could let it repudiate the whole thing. But if the company's own conduct gave the supplier reasonable grounds to believe the AI had authority up to ₹50 lakh, Section 237's estoppel logic could bind the company regardless of its internal instructions. This is genuinely fact-dependent, and the analogy itself is untested for autonomous AI systems.

Scenario C: The AI does something nobody anticipated

The company authorised its AI to negotiate a supply contract; the AI independently agrees to a three-year exclusivity clause nobody wanted. This is the hardest case because it's about subject-matter scope, not a numeric ceiling. Was exclusivity even within the AI's mandate? What did the supplier reasonably understand about that mandate? Did the company's documentation draw a clear, communicable line? Did the company object immediately on discovery, or keep operating under the contract in a way that looks like acceptance? There's no dedicated Indian rule for this; the outcome would turn on the evidence, and on whether and how a court chose to apply agency principles by analogy, which is exactly why authorisation wording, the vendor contract, and post-discovery conduct matter so much.

6. If the contract is valid, who bears the loss when the AI gets it wrong?

Validity and loss allocation are separate questions. Even inside a valid contract, an AI agent's mistake can generate real exposure: ordering the wrong quantity, agreeing to an excessive price, disclosing confidential information mid-negotiation, accepting an unfavourable indemnity, breaching an internal approval threshold, sending data to a third-party system, making an unauthorised payment, or misstating something to a counterparty.

Who absorbs each loss tends to depend on: the relationship between the parties; what the counterparty contract says; how much authority the company actually gave the AI and how that was documented; ordinary negligence principles (was the system deployed and supervised carelessly?); what was represented to the counterparty; any sector-specific regulation; and, often decisively, what the company's own AI vendor contract says about exactly this failure.

Under the current Indian legal framework, the AI system itself does not independently bear contractual liability because it is not recognised as a separate legal person capable of being sued in its own name. Liability must therefore be analysed by reference to the human or corporate actors involved, including the deploying business, vendor and, depending on the circumstances, other relevant parties. The loss always lands on a human or corporate party and working out which is largely a drafting and evidentiary exercise, not a doctrinal one.

7. Where real protection has to come from: The AI vendor contract

This is the most practical part of this article, and squarely within a company's control regardless of how unsettled the statutory picture is. Vendor contracts, and downstream customer and supplier agreements, increasingly need to address:

1.      Indemnities: Who compensates whom when the agent causes a loss? A generic indemnity for "breach of contract" or "gross negligence" is usually written with conventional software defects in mind, and it often does not clearly extend to a loss arising from an autonomous decision the system made using its own discretion within the bounds of how it was designed. The parties should consider whether the indemnity is intended to extend to autonomous, unauthorised, or unforeseen actions taken by the agent, and not only to bugs, downtime, or coding errors, and whether it covers third-party claims arising from the agent's conduct in negotiations or transactions carried out on the customer's behalf, so that the position is stated expressly rather than left to interpretation.

2.      Limitation of liability and carve-outs from the cap: Standard SaaS and technology contracts typically cap a vendor's aggregate liability at a multiple of fees paid, often twelve months' worth. That figure was calibrated for a world where the software's worst failure mode was an outage or a data error, not a system empowered to negotiate and commit to multi-lakh or multi-crore transactions on the customer's behalf. The parties should determine whether AI-driven losses fall within the general liability cap, a separate higher cap, specified carve-outs, or another negotiated allocation of risk, having regard to the scale of potential exposure. This is often a closely negotiated clause in agentic AI arrangements, and it is better addressed expressly than left to standard terms.

3.      AI-specific exclusions: Vendors will often attempt to exclude "hallucinations," model drift, or unauthorised autonomous actions from the scope of their liability altogether, treating these as inherent characteristics of the underlying technology rather than defects the vendor should answer for. Whether a business accepts that exclusion, and how it prices the resulting risk elsewhere, whether through insurance, a lower negotiated transaction ceiling for the agent, or additional human oversight layers, is one of the most consequential negotiating points in any agentic AI deployment today. Accepting a broad exclusion without a compensating risk-transfer mechanism elsewhere leaves the deploying business fully exposed.

4.      Warranties and performance standards: Beyond liability for failures, the contract may usefully set out affirmative warranties: that the agent will operate within the parameters the customer configures, that the vendor will not silently change the underlying model or its behaviour in ways that alter the agent's risk profile without notice, and that the vendor has tested the agent for the specific use case it is being deployed for rather than relying on generic benchmarks. Whether a vendor is willing to warrant basic behavioural boundaries, and on what terms, is a relevant indicator of how the parties intend to share performance risk.

5.      Data protection and confidentiality: What happens when the agent processes customer, employee, or counterparty personal data in the course of negotiating or transacting? This intersects directly with the Digital Personal Data Protection Act, 2023 (DPDP Act) and the Digital Personal Data Protection Rules, 2025 (DPDP Rules), which were notified in November 2025 and are being brought into force in phases, with most operational obligations due to take effect around May 2027. Section 8(2) of the DPDP Act contemplates that a Data Fiduciary engages a Data Processor under a valid contract, and the contract should therefore establish clearly whether the vendor is acting as a Data Processor on behalf of the business as Data Fiduciary, or in some other capacity, what its obligations are if the agent mishandles personal data, and how quickly it must notify the customer of any personal data breach involving the agent. Separately, and just as important commercially, the contract should specify whether the prompts, documents, and business information the agent is exposed to during deployment can be used by the vendor to train or improve its own models, or those of a third party. The contract should expressly state whether customer data, prompts, documents or outputs may be used for model training or improvement, rather than leaving the issue to potentially conflicting standard terms, privacy notices or platform policies. The answer may depend on the contract terms, confidentiality obligations, data-protection requirements, IP rights and the actual processing arrangement, and contractual silence does not by itself give a vendor a right to use protected material for that purpose.

6.      Security, incident response, and human oversight thresholds: What happens if the agent itself is compromised, whether through prompt injection, credential theft, a supply-chain attack on the underlying model, or manipulation by a counterparty's own system? The contract should specify security obligations proportionate to the agent's authority, a defined incident response and notification timeline, and who bears the cost of losses flowing from a security failure. Equally, the contract, or the customer's own deployment configuration that the contract references, should specify with real precision which categories of decision require a human to sign off before the agent executes them, defined by transaction value, subject matter, or both, rather than left as a vague commitment to "appropriate human oversight" that means nothing in a dispute.

7.      Audit rights and evidentiary access: Can the customer actually examine the agent's logs, decision records, and the instructions it was operating under, after the fact and without the vendor's cooperation being purely discretionary? Audit rights should be a contractual entitlement, not a courtesy, and should extend to the ability to request records in a dispute-ready format, not merely a dashboard summary. Without enforceable audit rights, a business has essentially no way to reconstruct what happened if a transaction is later challenged.

8.      Third-party models and subcontracting: If the vendor's agent runs on a foundation model built by an entirely separate provider, who answers for a failure that originates in that underlying model layer rather than the vendor's own application layer? The contract should require the vendor to disclose which third-party models it relies on, flow down equivalent obligations from its own upstream agreements, and confirm whether it can subcontract or delegate any part of the agent's processing further down the chain without the customer's prior knowledge or consent. A vendor that cannot answer this clearly at the negotiation stage is unlikely to be able to answer it during an actual dispute.

9.      Version control, model updates, and change management: Agentic AI systems are updated far more frequently, and far more substantively, than conventional software. A model update can materially change how the agent negotiates, what it agrees to, or how it interprets ambiguous instructions, without any change to the customer's own configuration. The contract should require advance notice of material changes to the underlying model or its behaviour, an opportunity to test the updated agent before it goes live on live transactions, and, ideally, the ability to roll back to a previous version if a change introduces unacceptable risk.

10.   Insurance: Existing cyber, professional indemnity and commercial liability policies should be reviewed to determine whether autonomous AI-related losses fall within coverage, exclusions or notification requirements, and written confirmation from the insurer may be advisable. Many existing policies were underwritten before agentic AI was a meaningful deployment category, so coverage should not be assumed. A gap between what the vendor contract allocates to the business and what the business's insurance actually covers is where uninsured losses tend to land.

11.   Governing law, jurisdiction, and dispute resolution: Where the AI vendor is based outside India, or where the agent negotiates with counterparties in other jurisdictions, the contract should fix governing law and jurisdiction with the specific risk of AI-driven disputes in mind, since the underlying facts (what the agent was told, what it did, and why) can be genuinely difficult to litigate or arbitrate across borders without clear evidentiary access built in from the outset.

12.   Records, retention, and litigation readiness: Finally, and perhaps most fundamentally: can the business actually prove, months or years after the fact, exactly what instructions the agent received and exactly what it did in response? Contracts that are silent on logging format, retention duration, and access rights leave businesses with essentially no usable evidence if a dispute over an AI-negotiated transaction ever proceeds to negotiation, arbitration, or litigation. Retention periods should be calibrated to realistic limitation periods for contractual claims, not to the vendor's own convenience.

8. Your contracts may need an AI clause, but not a generic one

If a business uses AI agents anywhere in its operations, its contracts across the board may need updating, not with one universal "AI clause" that gets pasted into every agreement, because no single clause fits every deployment, but with drafting deliberately tailored to the specific role, authority, and risk profile of the system in question. A customer-facing chatbot that answers billing queries carries a fundamentally different risk profile from a procurement agent authorised to commit to six-figure or seven-figure purchase orders, and the contractual language should reflect that difference rather than treating both the same way. The concepts below should be considered across every contract type an AI-deploying business maintains, adapted to that contract's specific context.

·        Customer contracts and terms of service: Where a business's own AI agent interacts with its customers, whether to negotiate pricing, process refunds, or accept orders, the customer-facing terms should disclose that an AI system may be involved in forming or executing the contract, define the limits of its authority in terms customers can actually understand, and set out what recourse a customer has if the agent makes an error, including how quickly a human will review a disputed automated decision.

·        Supplier and procurement agreements: Where the business's AI agent negotiates with suppliers, or where a supplier's own AI agent negotiates back, the agreement should specify the authorised scope and value ceiling for each side's system, whether either party's AI is permitted to bind the other to terms outside a pre-agreed template, and what happens if one party's system later disputes a term its counterpart's system agreed to. This is precisely the gap explored in the agent-to-agent negotiation scenario above, and it is best closed before deployment, not after a dispute arises.

·        SaaS and AI vendor agreements: These sit upstream of everything else and should consider, at a minimum, the matters discussed in Section 7 above: scoped indemnities, an appropriately calibrated liability cap, clear data protection and confidentiality terms, security and incident response obligations, audit rights, and disclosure of any third-party models the vendor's agent relies on.

·        Internal delegation policies and employment terms: This is the piece most businesses overlook. Even a perfectly drafted set of external contracts provides limited protection if any employee can quietly expand what the company's AI agent is authorised to do, without documentation, sign-off, or a paper trail. Internal policy should specify who within the organisation has authority to configure or expand an agent's permissions, what approval is required before a change takes effect, and how changes are logged and reviewed. This is, in effect, the internal mirror of the external authority questions discussed throughout this article, and getting it wrong internally can undo careful drafting everywhere else.

Core Contract Checklist Items:

1.      The precise, documented scope of what the agent may do, expressed in terms specific enough to be evaluated in a dispute

2.      Clear transaction-value limits calibrated to the business's actual risk appetite, not a generic industry benchmark

3.      Mandatory human approval for specific, precisely defined decision categories, by value, subject matter, or both

4.      An explicit list of prohibited actions the agent must never take, regardless of how it interprets its broader instructions

5.      Escalation triggers for ambiguity the agent is not equipped to resolve on its own

6.      Audit logs detailed enough to hold up as evidence, with retention periods matched to realistic limitation periods

7.      Authentication requirements confirming which system, version, or configuration actually took a given action, so that it can be shown which authorised system generated a given communication or transaction (see the discussion of authority and authentication in Section 4)

8.      Incident notification timelines, and suspension rights allowing the business to pull the agent's authority immediately

9.      Indemnities, liability caps, and insurance coverage reviewed specifically against AI-driven losses, not assumed to already apply

10.   Termination rights tied to repeated or serious unauthorised actions by the agent or its vendor

11.   Change-management provisions covering model or behaviour updates that could alter the agent's risk profile

12.   Clear allocation of responsibility as between the business, its AI vendor, and any third-party model provider in the chain

A business that carefully drafts its external contracts but leaves internal policy on who can expand an agent's permissions unregulated has only closed half the gap. The external protections are only as strong as the internal governance standing behind them, and a dispute will test both.

9. The human click may disappear, but responsibility doesn't

Autonomous systems create a genuinely hard attribution problem, because many hands touch the outcome without any one looking like the obvious cause: the deploying company, the vendor, the employee who configured it, the counterparty who relied on it. Recent commentary on India's AI governance landscape captures this directly: when autonomous agents interact and something goes wrong, responsibility splinters across developers, deployers, and integrators, each individually compliant even as harm arises from how their systems interacted. Current Indian guidance remains largely voluntary and wasn't designed with fully autonomous decision-making specifically in mind.

That's not a claim that India "has no AI regulation"; that overstates the gap. The IT Act, Contract Act, DPDP Act, sectoral rules, and tort principles all continue to apply according to their terms and do real work. What's missing is a dedicated rule for autonomous AI contracting specifically, and until one exists, businesses are working with tools built for a world where every commitment had a human behind it in real time.

10. Does India have a law specifically governing AI agents?

Not yet, as of September 2026. MeitY released the India AI Governance Guidelines in November 2025 under the IndiaAI Mission, India's first comprehensive AI governance framework, organised around seven guiding principles, six governance pillars, and a phased action plan. Crucially, the Guidelines deliberately avoid a separate AI statute, relying instead on existing legislation and institutional oversight. They are governance guidance and policy direction, not a statutory liability regime: they do not create binding, AI-specific liability rules for autonomous contracting, and say nothing definitive about an autonomous agent exceeding its authority in a negotiation.

Separately, industry work on agentic-AI liability is developing. Reporting from August 2026 indicated that the Data Security Council of India (DSCI) was working on a framework examining responsibility across the AI value chain (businesses deploying agents, enterprises integrating them into products, and providers of the underlying tools), with allocation depending on factors like the AI model chosen and how the agent is developed and governed. Any such framework should not be treated as an operative standard unless and until it is published and adopted.

In the meantime, the operative tools remain the IT Act's provisions on electronic contracts and attribution, the Contract Act's general principles (with agency principles available at most by analogy), the DPDP Act and DPDP Rules for personal data, sectoral regulation (RBI, for instance), and general consumer-protection law. There is no dedicated Indian statute stating who is liable when an AI agent exceeds its authority in forming a contract.

In B2C deployments, the Consumer Protection Act, 2019 adds another layer of potential exposure. If a customer-facing AI agent makes unauthorised promises such as erroneously confirming a refund, granting price discounts, or misrepresenting product terms, the business cannot easily disclaim liability by citing model error alone. Depending on the representation and surrounding facts, customer-facing AI statements may engage the Consumer Protection Act, 2019, including provisions concerning misleading advertisements and unfair trade practices (Sections 2(28) and 2(47)). A business may therefore face consumer-law exposure even where the statement resulted from an internal AI configuration error.

11. A brief look elsewhere: context, not import

The EU AI Act (Regulation (EU) 2024/1689) imposes human-oversight and robustness obligations on high-risk systems, although the Digital Omnibus on AI (Regulation (EU) 2026/1744) has deferred their application to 2 December 2027 for stand-alone (Annex III) systems and 2 August 2028 for AI embedded in regulated products (Annex I). The revised EU Product Liability Directive (Directive (EU) 2024/2853) brings software and AI within "product" scope for strict liability; Member States must transpose it by 9 December 2026, and it applies to products placed on the market after that date, a materially different starting point from India's fault- and contract-based approach. Singapore's IMDA released version 1.0 of its Model AI Governance Framework for Agentic AI on 22 January 2026 (updated in May 2026). It is voluntary guidance built around four dimensions: assessing and bounding risks, meaningful human accountability, technical controls, and end-user responsibility.

These are useful reference points for cross-border businesses and for benchmarking good practice, but none applies automatically to an Indian business operating in India (although a business with EU or Singapore operations or customers may fall within their scope), and none should be cited as though it were Indian law.

12. What happens when one AI agent negotiates with another?

Push the scenario further: your procurement agent negotiates directly with a supplier's own AI agent, with no human on either side involved. The two systems agree on price, delivery, and payment terms between themselves.

Who authorised the deal? What evidence shows what each system was told to do? What happens when the two systems interpret their instructions differently, and the resulting "agreement" reflects a mismatch nobody caught? There's no settled Indian answer here, but the scenario makes plain why authority documentation and audit trails matter more, not less, as agent-to-agent transactions become ordinary rather than exceptional.

13. Before you let an AI agent sign anything, ask these ten questions

1.   What exactly is the agent authorised to do, described precisely enough for a court to evaluate?

2.   What is the maximum value of any single transaction it can commit to?

3.   Which decisions require explicit human approval first?

4.   Can it negotiate terms, or only execute terms a human already agreed?

5.   Can it accept binding terms without further confirmation?

6.   What happens, contractually and operationally, if it exceeds its instructions?

7.   Are its actions logged durably enough to serve as evidence?

8.   Can the business reconstruct its full decision path after the fact?

9.   Who bears liability under the AI vendor agreement if it goes wrong?

10.Does the company's insurance actually respond to autonomous AI-related losses?

14. Frequently asked questions

Can an AI agent legally sign a contract in India?

Not as a legal person: under the current Indian legal framework, an AI system is not recognised as capable of holding contractual rights and obligations in its own name. A contract executed through a company's AI system can still bind that company, depending on authority and how the transaction unfolded.

Is a contract made by AI automatically valid?

Section 10A means the electronic form isn't a barrier. Validity still depends on the usual essentials: genuine offer, acceptance, lawful consideration, and actual or apparent authority to bind the relevant party.

Who is responsible if an AI agent exceeds its instructions?

Courts may look to the Contract Act's rules on principals and agents by analogy, although whether those rules apply to autonomous AI systems is unsettled. If they do, the answer depends on whether the excess is separable (Section 227), whether the transaction is indivisible (Section 228), and whether the company's own conduct made the excess look authorised (Section 237).

Can a company deny a contract because its AI made the decision?

Not simply by pointing at the AI. It would need to show the AI acted outside authority in a way the counterparty couldn't reasonably rely on, and continuing to perform the contract afterward could undercut that, including through ratification if agency principles are applied by analogy.

Can an AI agent be treated as an "agent" under Indian contract law?

Not as settled law: no statute or judgment extends the Contract Act's definition of agent to AI systems. Agency principles are a useful lens, not a formal classification.

What happens if an AI agent makes an unauthorised payment?

If agency principles are applied by analogy, the analysis would turn on authority and ratification, as for a human representative, and would need to be considered alongside what the AI vendor contract says about liability for that failure.

Should AI vendors provide indemnities for autonomous actions?

Whether a vendor indemnifies for autonomous actions, and to what extent, is a matter for negotiation and depends on the contract terms; it should not be assumed to be included by default.

Can businesses limit an AI agent's contractual authority?

Yes, and doing so clearly, in a way the counterparty can see or reasonably infer, is one of the few concrete steps available right now, regardless of how the law develops.

The takeaway

The difficult question is no longer simply whether AI can draft a contract. It's whether the law can determine who is responsible when AI moves from drafting words to making decisions.

Until India's legal framework develops further, whether through industry frameworks, official guidance, or eventual legislation, businesses deploying AI agents need to pay close attention to how authority is defined, where human oversight actually sits, how thoroughly actions are logged, and how contractual risk is allocated between the company, its counterparties, and its vendors. No single party is always left holding the loss. The answer depends on the facts, and right now, the facts are what the law has to work with.

Author

This blog was reviewed by Rakshika Bajpai, a corporate lawyer specialising in IPR, contract drafting, and compliance advisory. She is a technology-driven legal professional focusing on corporate compliance and data-privacy frameworks at SolvLegal. Her work spans IT law and cross-border regulatory matters, and she supports businesses in protecting their innovations and strengthening their legal and compliance structures.